\documentclass[12pt]{article}
\usepackage{fullpage}
\usepackage{listings}
\usepackage{setspace}\usepackage[colorlinks=true,urlcolor=blue,linkcolor=black,citecolor=red]{hyperref}
\usepackage{url}
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{supertabular}
\usepackage{epsfig}
\include{pigasus.lst}
\usepackage{courier}
\usepackage[colorlinks=true,urlcolor=blue,linkcolor=black,citecolor=red]{hyperref}
% Use a small font for the verbatim environment
\makeatletter  % makes '@' an ordinary character
\renewcommand{\verbatim@font}{%
  \ttfamily\footnotesize\catcode`\<=\active\catcode`\>=\active%
}
\makeatother   % makes '@' a special symbol again
\begin{document}

\begin{titlepage}
\begin{center}

\vspace*{3in}

{\huge Pigasus}

{\it The Final Report}

\vspace*{0.5in}

COMS W4115

\today

\vfill

\end{center}

\begin{flushright}

{\bf Team Hogzilla}

{\it Project Manager:} John Zhang (jrz2106)

{\it System Architect:} Sharath Gururaj (sa2617)

{\it Language Guru:} Jordan Rupprecht (jjr2119)

{\it Verification and Validation Person:} Philip Tjimos (pmt2103)

{\it System Integrator:} Everyone

\end{flushright}
\end{titlepage}

\setcounter{secnumdepth}{5}
\setcounter{tocdepth}{4}

\tableofcontents

\listoffigures

\listoftables

\newpage

\section{Introduction}


\subsection{Introduction}

We introduce the Pigasus programming language. Pigasus is a light-weight language designed for distributing computing jobs across an arbitrary network to allow programmers to make use of multiple machines concurrently.

In many scenarios, programmers may be presented with problems that are clearly parallelizable, that is, programs with routines that can run on different sets of input data independently. Solutions to these problems can execute more efficiently by taking advantage of multiple threads or machines. For programmers with the need to execute computationally-intensive programs and have access to a number of networked machines and high bandwidth, the advantage of distributing a program onto multiple machines is clear.

Similarly, there are many scenarios where a programmer may need to execute a single-threaded program on multiple data inputs. Common examples include software testing, or scientific simulations. Automating the execution of these tasks on multiple machines would save time and effort.

Pigasus addresses both these situations (and possibly others) with an emphasis on the latter. Programmers will be able to write a program (using any other language) to create an executable binary and use Pigasus to distribute the binary and specify and manipulate the different input sets and gather the output. Thus, programmers will be able to focus on writing the code to solve their problem and minimize their need to deal with the task of managing the network and distributing their code.

\subsection{Motivation}

Pigasus was motivated by the work of two of the team members.  In a previous course project, a resource-intensive simulation needed to be run on several data sets with many different configurations. Ultimately, a more efficient approach was taken by distributing the workload across the machines in the students' computing cluster. This was done by automating the process of manipulating the configurations and distributing the script and associated binaries to the cluster machines and executing remotely. This was accomplished using Python and Bash scripts. Of course the solution was ad-hoc and time consuming to implement.

Our group realized that the solution could be generalized to cater to similar distributed problems. The main target groups of our language would be students and researchers who want to run heavy simulations without investing in extensive hardware, or the time to set up such an environment.

\subsection{Existing Work}

Two of the most popular distributed frameworks currently used are MapReduce and Hadoop.

MapReduce is a software framework created by Google to process large datasets using their large computing clusters. It is a specialized framework implemented in existing languages such as Java and C++ so software using MapReduce must conform to a specification. The remote machines must also conform to a certain setup but have powerful features including data replication and load balancing. The MapReduce model is divided into the ``map'' and ``reduce'' phases. In the map phase, input data is split into chunks and the mapper routine is applied on each chunk independently. The results of the map phase are separated according to keys and, for each key, merged according to the reduce routine.

Hadoop is an open source implementation of MapReduce used by, among others, Yahoo to run their search algorithms.

The extensive setup required and the specialized code make it impractical for private individuals. While Pigasus lacks some of the power of MapReduce and Hadoop, it has the advantage of being simple and extensible from existing binaries. Software does not need to be written especially for Pigasus, and remote machines do not require the specialized setup.

\subsection{Buzzwords}

Pigasus is simple, distributed, secure and system integrated.

\subsubsection{Simple}

Pigasus code is clean, compact, and easy-to-read. Using Pigasus, programmers will have the ability to run jobs on multiple machines across a network with a minimal amount of code related to network programming, load balancing or secure communication.

Furthermore, Pigasus requires no special setup for remote machines. All that will be required to use a remote machine is that it be running a Unix-based system (e.g. Linux or Mac) and is accessible by the programmer via SSH / SCP (i.e. the programmer has an account on that machine). This is an advantage over many existing distributed frameworks such as MapReduce and Hadoop which require special software running on the remote clusters before using them (although these frameworks are considerably more powerful).

\subsubsection{Distributed}

This language allows programmers to send jobs to multiple computers/servers in order to execute arbitrary programs with different inputs. The same program can be sent over a network and executed several times, with different or same inputs, with data collected at the end. This allows someone from a laptop or a cheap PC to run resource intensive processes on a computing cluster as if it were their own computer.

\subsubsection{Secure}

Utilizing SSH  allows for secure transfer of data, user names, passwords, and anything else that the programmer may send and receive. Since all remote commands are issued through the shell under the user's permissions, all the actions are restricted to those same permissions. The user wouldn't be able to do anything that they couldn't already do sitting at the machine physically.

\subsubsection{System Integrated}

Pigasus programmers will easily be able to access the shell. If something cannot be accomplished efficiently with Pigasus, or if there is already existing code written, Pigasus can instead interact with that code. Pigasus can simply provide the input and/or process the output. This would be useful, for example, if you are forced to use a closed-source binary as part of your simulations, and there is no other way to produce the output that the binary can.

\subsection{Applications}

Use of Pigasus may be beneficial for anyone with access to a group of networked machines (particularly if these machines are often idle) and high bandwidth, while operating on a low budget and therefore cannot afford to purchase computing time on a large computing cluster such as Amazon's EC2 service. Students, researchers, engineers working at small companies may find this particularly useful. In the near future, this may also be useful for mobile computing, as battery-sensitive devices can utilize remote CPU power instead of draining their own batteries. Some possible applications include:

\begin{itemize}

\item Distributed 3D rendering.
\subitem Often, a large number of 3D images need to be rendered. A raytracer could be written in C/OpenGL, compiled and pushed out to multiple machines where different images are rendered based on the parameters.
\item Distributed code compilation.
\subitem Source code for large software engineering projects may be pushed out to multiple machines and compiled individually (e.g. produce object files for C code). Then, they can be pulled back to the host machine where they can be linked together. One example of an existing distributed compiler is distcc.
\item Research simulations.
\subitem In many areas of research, simulations need to be run on different data sets. The benefit of distributing the simulations is clear.
\item Pushing single jobs to a remote machine.
\subitem Many students own low-powered laptops. Pushing large computing jobs (e.g. an assignment) out to a remote machine would enable the student to use their laptop for other purposes.

\end{itemize}

There are also many situations where people not falling in one of the aforementioned categories may find Pigasus useful. For example:

\begin{itemize}
\item Setup several machines simultaneously.
\subitem Suppose a person owns multiple machines (e.g. a desktop and a laptop) and wishes to install the same set of software on them. After installing Linux and SSH manually (which is often automatic in the installation of Linux), Pigasus can be used to distribute and run shell scripts to configure the machines simultaneously. Pigasus does {\it not} need to be configured on the remote computers for this to be done.

\end{itemize}
 
\subsection{Sample Code}

Three examples of Pigasus code are provided here. The first is the Pigasus version of the classic ``hello world'' program where a remote machine is commanded to print \verb|hello world| to the standard output which is then pulled back to the host machine. Please note that these were an early imagining of what we hoped Pigasus code would resemble.


\begin{quote}
\begin{verbatim}
// We'll use Java/C++ style comments and templates. Square brackets denote a
// list. Note that the Server type is a specialized list, with the elements
// being (in order): the remote machine, username, password, and path to private
// key (if applicable).
List<Server> servers = [ 
  [ "compute.cs.columbia.edu", "student", "pass", null ]
];

// All functions with return type Job are executed on a remote machine. They are
// passed a unique job_id first.
Job HelloWorldJob(Integer job_id) {
  ExecuteShellCommand("echo \"Hello World!\"");
}

// The Main function is the program entry point.
Main(List<String> argv) {
  Connect(servers);

  // RunJob is a special function which automatically pushes a single job out 
  // to a machine and returns the job_id. 
  Integer job_id = RunJob(HelloWorldJob);

  // Output is a special structure used to access the files (including stderr,
  // stdout) returned by remote machines. We also adopt the Python % operator,
  // which is essentially a StringPrintf(). Furthermore, all lists will be
  // associative and accessible by strings as well as integers.
  Print("%s\n", % Output[job_id].GetStdout());
}
\end{verbatim}
\end{quote}

One of the sample applications listed was a Pigasus implementation of a
distributed compiler such as distcc. While distcc has advanced options, the
basic functionality would be easy to implement using Pigasus.

\begin{quote}
\begin{verbatim}
// We'll demonstrate how multiple servers can be listed here. We introduce the 
// ~n operator, which makes a value the default value across the n-th dimension
// (1st dimension would be rows, 2nd would be columns, etc.). The benefit of 
// using a matrix to specify servers is that the specification could be created
// using a common spreadsheet editor and saved as a CSV file, which could be 
// imported with a special Pigasus function.
List<Server> servers = [
  [ "compute01.cs.columbia.edu", "student"~2, "pass"~2, null~2          ],
  [ "compute02.cs.columbia.edu",            ,         ,                 ],
  [ "compute08.cs.columbia.edu",            ,         ,                 ],
  [ "clic.cs.columbia.edu"     , "alice"    ,         , "~/.ssh/id_rsa" ]
];

Job CompileFileJob(Integer job_id) {
  String c_source = Inputs[job_id].GetFileName();

  // This will produce the object file <job_id>.o.
  ExecuteShellCommand("gcc -c %s -o %d.o" % [c_source, job_id]);
}

Main(List<String> argv) {
  // Inputs is a special variable containing files / data associated with each
  // job separated by job ID. We also adopt Python 'slice' notation, so 
  // argv[1:] returns all elements of argv minus the first one.
  Inputs = LoadFilesToSend(argv[1:]);

  Connect(servers);
  
  List<Integer> job_ids = RunJobs(CompileFileJob);

  String link_cmd = "gcc";
  Boolean success = True;
  for (Integer j in job_ids) {
    if (Output[j].GetStderr() != "") {
      Print("Error found in file %s:\n%s\n\n" % [ Inputs[j].GetFileName(),
                                                  Output[j].GetStderr() ]);
      success = False;
      break;
    }
    link_cmd += " " + j + ".o";
  }

  // Link to produce a.out.
  if (success) {
    ExecuteShellCommand(link_cmd);
  }
}

\end{verbatim}
\end{quote}

\subsection{Conclusion}

The goal of Pigasus, as seen in the sample code, is to make distributing jobs
very simple and straightforward. Since the only prerequisite for Pigasus is a UNIX environment, with tools such as SSH, it can be run on almost any non-Windows computer. We have identified many categories of users and applications which might find Pigasus useful. There are many other applications which would be simple given a language like Pigasus. 

\section{Tutorial}

\subsection{Introduction}

We will present here a brief tutorial for writing a Pigasus program. It is our goal that by reading the tutorial and examining the code, the reader will have sufficient information to use most if not all of the key capabilities of the Pigasus language.

In this tutorial, we will demonstrate the process of establishing connections, distributing jobs and input files, and handling the output of the distributed jobs.

Pigasus is heavily inspired by C, with inspirations from Python. An experienced programmer in either language (or related languages such as C++ and Java) should be able to become comfortable programming with Pigasus quite quickly. While this tutorial will describe general programming constructs such as if-statements, loops, etc., they will not be focused on, and instead we will assume that the user has some experience with common programming languages (or is at least willing to refer to them).

\subsection{The Pigasus Compiler}

Pigasus code can be written in any regular text editor, and the resultant file must have a ``.pig'' extension. These are then used as input to the pigasus compiler (the \verb|pig| executable). Unless another output filename is provided, the compiler will produce an executable named \verb|pig.out| (get it?).

Therefore, suppose you have the Pigasus code \verb|helloworld.pig|, you can compile and execute as follows from the Unix prompt.
\begin{quote}\begin{verbatim}
$> pig helloworld.pig
$> ls
pig.out
$> ./pig.out
\end{verbatim}\end{quote}
A different output filename can be specified using the \verb|-o| parameter (same as \verb|gcc|).

\subsection{A First Program}

We will follow computer science tradition and provide an introductory Hello World program.

\subsubsection{A Simple Hello World}

Here we present a basic program that runs ``Hello, World'' on the remote computer. For now, we will ignore the process of retrieving the output from standard-out.

\begin{lstlisting}[caption=A first ``Hello World'' program.]
job RunHello(list inputs) { 
  @{"echo hello world"};
}

void main(list args) {
  list my_servers = [["host"=>"localhost",
                      "user"=>"dummy",
                      "password"=>"dummypw"
                     ]];
  connect my_servers;
  
  list output;
  push RunHello, null, null, output;
}
\end{lstlisting}

The beginning of the program defines a \verb|job|, which contains the code that gets executed on the remote machine. The syntax is kept similar to a regular function call, mostly just to make it familiar to experienced programmers. Within the job {\it RunHello}, we do only one thing: run the shell script \verb|echo hello world|. We use the syntax \verb|@{<string>}| to execute something in the shell.

The next part is the {\it main} function. This does the minimal things required to compile a Pigasus program: it declares the servers it wants to use for computing, connects to them, pushes the job out to those computers, and then exits.

The first part of this code declares the {\it my\_servers} variable as a list of maps. These are two distinct data types native to Pigasus:
\begin{description}

\item[list] is a type similar to a \verb|vector| in C++ or a \verb|List| in Java. A unique aspect of \verb|list|s in Pigasus is that it can have elements of different types. In our first example program, we don't use this fact, but it is important to know. Elements in list can be accessed using an integral index.

\item[map] is a type similar to a \verb|map| in C++ or a \verb|Map| in Java. It takes a \verb|string| as an index and returns an object or \verb|null| if there is no such index. As with \verb|list|s, one can have a \verb|map| that contains values of different types, but the keys themselves must all be \verb|string|s.
\end{description}

The {\it my\_servers} list has been filled with only one element, a \verb|map|
that maps important keys for the connection information to the values that
should be used. The intention is that most users will only have to define the
values for the keys ``host'', ``user'', and ``password''; if someone has other
values that are important, such as ``port'' (if port 22 for SSH is not
available), ``key\_file'' (to use SSH keys instead of a password), or
``priority'' (to give faster servers a weighted priority), maps have that
flexibility. 

The next line, \verb|connect my_servers| is a directive to Pigasus, telling it that it should use the \verb|my_servers| servers list when it pushes jobs. Most users will only need to apply this directive once in a program, but there could be instances where one would want to change the global list of servers to use.

Finally, the next line does the actual push of the job. The first argument of \verb|push| is the job name that we want to execute. The next three arguments are for syncing files, specifying inputs, and capturing output. We will illustrate their usage in future sections. Since the first two inputs are all left as \verb|null|, it is implied that we don't need to sync any files and we want to run it once with no specific inputs. The last input is an empty list. A list must be the final argument of push and by using an empty list we are saying that we do not care about output.

\subsubsection{Advanced hello}
In this example, we will do the same thing, but show off a few features.

\begin{lstlisting}[caption=A more advanced ``Hello World'' program with file transfer and CSV loading.]

\end{lstlisting}

A few things have changed here, to make it cleaner and more generic. The first change is in the job we use. Instead of running \verb|echo hello world|, we run \verb|./hello|, which is a precompiled program. File \verb|hello| could be a bash script that calls \verb|echo hello world|; it could be a C program that calls \verb|printf("hello world\n");|, etc. All Pigasus cares about is that it is an executable. This will be run on the remote server, so if the \verb|hello| program is not on the remote server, it will result in an error. For now, we assume that it is.

The second change is in the servers definition. In order to make defining servers a little easier, we provide the option of loading in values from a CSV (comma separated values) file. This can be applied to load any list, but it is particularly useful for a list of servers. In fact, we would strongly advise that users keep their server definitions separate in CSV files. This is because Pigasus code, (like any other code) may eventually be shared, and it would be disastrous if one included account passwords in their code which they sent to others. Futhermore, we would even suggest that users of Pigasus generate SSH key files instead of explicitly specifying their passwords in unencrypted text files.

The final change is that, since \verb|hello| is not on the remote server, it must be sent there. We must now provide the second argument of \verb|push|, which is a list of all the files to transfer. Providing this list of files will ensure that before we start any jobs, we send those files to all the servers which we run jobs on.

\subsection{Distributed Temperature Converter}

Here we consider another program from the text \cite{kernighan:c}, with a Pigasus twist. We implement a Fahrenheit to Celsius converter, sending each calculation to a different machine. This is obviously wasteful with respect to overhead, but it would make sense if the conversion took several hours and could take advantage of multiple cores (and your laptop only has one or two cores).

In this example, we assume that there is a program called \verb|ftoc| which converts a Fahrenheit value to a Celsius value. This can be easily implemented by the bash command \verb\echo ("$1"-32)*5/9 | bc\ (\verb|$1| will assume the value of the first argument).

\begin{lstlisting}[caption=A distributed Fahrenheit to Celsius converter]
job RunFtoC(list inputs) {
  @{"./ftoc %d" % [(int)inputs[0]]};
}

void main(list args) {
  list my_servers = [["host"=>"localhost",
                      "user"=>"dummy",
                      "password"=>"dummypw"
                     ],
                     ["host"=>"localhost",
                      "user"=>"dummy2",
                      "password"=>"dummypw2"
                     ]];
  connect my_servers;
  
  list my_ints;
  int i;
  for (i = 0; i < 10; i = i + 1) {
    my_ints = my_ints + [[i*20]];
  }
  print ("Length = (%d)\n" % [length my_ints]);
  
  list my_files = ["ftoc"];
  
  list output;
  int conversion = push RunFtoC, my_files, my_ints, output;
  wait conversion;
  
  for (i = 0; i < length output; i = i + 1) {
    map out = (map)output[i];
    print ("F: %d\t C: %s" % [(int)(((list)my_ints[i])[0]), (string)(out["stdout"])]);
  }
}

\end{lstlisting}

We finally utilize all components of the \verb|push| directive: we need to tell it what job to push, we need to send the program that can convert a single Fahrenheit value to Celsius, we need to tell which jobs to run which inputs, and finally, we care about the output.

Since each job needs a list on inputs which it needs to be run with, the \verb|push| directive needs an input list for each job instance, which means that it needs a list of lists. The number of job instances which will be created is equal to the length of the inputs list (with the exception being if the list is \verb|null|). So, we create a list that contains \verb|[[0], [20], [40], ...]|, so that the first job instance will be run with the input list \verb|[0]|, the second job instance will be run with the input list \verb|[20]|, and so on.

To create this input list, we make use of a \verb|for| loop. This is a basic construct used in almost all programming languages. The first section is the initializer, which executes before every loop iteration. This is useful for initializing a loop counter, which we do here. The second section is the test expression, which is evaluated before every loop iteration. If the value of the test expression is \verb|false|, then the for loop stops and the point of execution progresses past the block of code for the for loop. The final section is the post section, which executes after every loop iteration. This is useful for incrementing a loop counter, which we also do here. In our example, we initialize a loop counter to zero, and increment it until the value reaches 10. This ensures that the loop will be run exactly 10 times.

Following the for loop is a section of code contained by \verb|{| and \verb|}|. This gets executed 10 times, and during each execution, the value of {\it i} increments. The single line of code we execute here is a list append operation. The \verb|+| operator here has been overloaded from the usual addition syntax to a list append syntax.

On the first run of the for loop, {\it my\_ints} is an empty list. By appending \verb|[i*20]| to the current value of {\it my\_ints}, we essentially initialize {\it my\_ints} to \verb|[[0]]| (the initial value of {\it i} is 0). On the second run, {\it my\_ints} is already initialized, so instead of creating a new list, we merely append to one. The result after the second loop iteration is \verb|[[0], [20]]|. This pattern continues until the list is full of 10 lists, each with a single integer value that is larger than the previous one by 20.

With all the setup done, we push the job. Note that we have initialize the {\it output} variable, which will be filled with the output contents once the job has finished. The most interesting point, however, is that we are passing inputs to the job. This is reflected by the use of inputs in the job definition.

In the body of the job we run, \verb|job RunFtoC|, we use the usual syntax of simply running a single program, but we use the inputs to run the same job but with different command line inputs on each computer. While we declared the input list, {\it my\_ints}, to be the list \verb|[[0], [20], [40], ...]|, each job only sees one list item. So, for example, on one computer, the job will receive inputs as the list \verb|[120]|. In order to extract the first element of the list, we can use the syntax usually used for array indexing in a language, \verb|inputs[0]|.

In order to execute the program, we must provide a string to execute. However, the string to execute is different for each job instance. For instance, one will need to execute \verb|ftoc 20| on one computer, and \verb|ftoc 160| on another. Thus, we need to be able to do string manipulation. To do this, we adopt the \% operator from Python, which allows for printf-like statements anywhere. In other words, printing the string \verb|"ftoc %s" % [(int)inputs[0]]| is equivalent to calling \verb|printf("ftoc %s", inputs[0])| in C.

After the job has been pushed to the remote computers, \verb|push| returns. In order to know when it returns, we capture the return value of it, and then call \verb|wait conversion|, which waits for the job with the id specified by {\it conversion} to finish. This call blocks, so execution halts until the job finishes.

After we are done, we want to print the results of the conversion. For this, we iterate over the {\it output} variable with a for loop. The only difference in the for loop declaration is that we test again the loop iterator being less than the length of the output list instead of a constant. We use the \verb|length| command to determine the length of a list (or map).

In order to output a string to standard out, we provide the \verb|print| syntax, which takes a string and sends it to \verb|stdout|. In this example, we use the \% syntax as we did before. In this case, however, there are multiple values we want to format into this string. In the previous example, we had only one value, so we could use the \% operator followed by a list of one or more variables to fill the formatter with. Here, in order to include several values into the format string, we provide a list to the right of the \% operator.

\subsection{Distributed C Compiler}
In this section, we implement a barebones version of \verb|distcc|, a program that distributes compilation over the network. It does this by sending out source files, compiling them there, and sending the object files back and linking them together locally. Here we hardcode it, sending out four source files, and linking them to create a \verb|MyCoolProgram| binary.

\begin{lstlisting}[caption=A stripped down distcc.]
job compile(list inputs) {
  @{"gcc -c %s" % [(string)inputs[0]]};
}

void main(list args) {
  list my_servers = [ [ "host"=>"localhost",
                        "user"=>"dummy", 
                        "password"=>"dummypw" ] ];
  connect my_servers;
  
  list srcs = [[(file)"a.c"], [(file)"b.c"], [(file)"c.c"], [(file)"d.c"]];
  
  list output;
  int distcompile = push compile, null, srcs, output;
  wait distcompile;
  
  string ld = "gcc -o MyCoolProgram";
  
  for (int i = 0; i < length output; i = i + 1) {
    map out = (map)output[i];
    for (int j = 0; j < length (list)out["files"]; j = j + 1) {
      ld = "%s %s/%s" % [ld, (string)out["root"], (string)((list)out["files"])[j]];
    }
  }
  
  print(ld + "\n");
  @{ld};
}

\end{lstlisting}

There are two major differences in this piece of code. The first is in how we implement \verb|push|. We pass \verb|null| in place of the files to send, since the only relevant file which {\bf all} jobs need is \verb|gcc|. We assume this is already on all the computers. However, each job needs the source code it is compiling to be sent. This is implemented by passing the files into the input list. However, in order to let Pigasus know that this is a file we are passing over, we cast it as a \verb|file|. Then, when the job executes, it sees the name of the file as a string, but the file itself will also be sent automatically.

When the job finishes, it will detect which files have been created or modified, and it sends those back. However, in the case that separate jobs might produce files with the same name, they are separated into different directories. Thus, the list of files is represented by the \verb|out["files"]| list, but the files are all in the directory \verb|out["root"]| (which is a directory relative to the current working directory).

Finally, when we have parsed through the entire outputs list, we have then finished the string which we can use to link the program. If, for instance, Pigasus places the files for the four jobs in folders 1, 2, 3, and 4, then the contents of the \verb|ld| string will be \verb|gcc -o MyCoolProgram 1/a.o 2/b.o 3/c.o 4/d.o|. We can then execute this on the local machine by running \verb|@{ld}|.

\subsection{Alternate syntax}
Here, we experiment with different syntaxes that do essentially the same things as before. Specifically, we provide an example that illustrates keywords \verb|connect|, \verb|while|, and \verb|waitall|.

\begin{lstlisting}[caption=Another Pigasus Program]
job Echo(list inputs) {
  @{"echo %d" % [(int)inputs[0]]};
}

job Double(list inputs) {
  @{"echo -n %d" % [2*(int)inputs[0]]};
}

void main(list args) {
  //declare servers
  list first_servers = [["host"=>"localhost",
                         "user"=>"dummy",
                         "password"=>"dummypw"
                         ]];
  list second_servers = [["host"=>"localhost",
                          "user"=>"dummy2",
                          "password"=>"dummypw2"
                          ]];
  
  connect first_servers;
  
  list first_inputs;
  int i = 0;
  while (i < 5) {
    first_inputs = first_inputs + [[i]];
    i = i + 1;
  }
  
  list first_output;
  push Echo, null, first_inputs, first_output;
  waitall;

  list second_inputs;
  i = 0;
  while (i < length first_output) {
    second_inputs = second_inputs
      + [[ (int)((string)((map)(first_output[i]))["stdout"]) ]];
    i = i + 1;	
  }
  connect second_servers;
  
  list final_output;
  int x = push Double, null, second_inputs, final_output;
  waitall;
  
  for (int i = 0; i < length final_output; i = i + 1) {
    print "Final Result is: %s.\n" % [(string)((map)(final_output[i]))["stdout"]];
  }
}


\end{lstlisting}

The first thing to notice is that we have two separate jobs defined. The first command in {\it Echo} simply prints out the first input. In the {\it main} code, we define two different lists of servers, but we initially only connect to one of them. We then begin to prepare the variables for pushing the job. Here, instead of using the usual \verb|for| loop, we implement a \verb|while| loop. Although the two loop types are very similar, sometimes one is more natural than the other. The \verb|while| loop executes the body for as many times as the expression in the parentheses is true. If it is not even true the first time, it will never execute the body; if the statement is a \verb|while (true)| loop, it will never stop executing the loop, unless there is a strong breaking statement such as \verb|break| or \verb|return|.

We now are ready to push the job as usual. Before, we always grabbed the return value of \verb|push| in order to wait for it to finish. However, we can make use of a different keyword, \verb|waitall|, which blocks until any and all jobs that have been pushed so far finish executing. This is convenient in many cases: if we only have one \verb|push| statement, we might as well use \verb|waitall| instead of bothering to retain the return of \verb|push| and use \verb|wait|; if we have many \verb|push| statements, it is a lot easier to say \verb|waitall| instead of calling a \verb|wait| for every \verb|push|.

\subsection{Rendering Test}

We provide the code here for a program that benefits greatly in terms of performance using Pigasus. This program renders images for a video and is easily parallelizable.

\begin{lstlisting}[caption=A program for rendering a video.]
job Render(list inputs) {
  int orig = (int)inputs[0];

  for (int c = 0; c < 100; c = c + 1) {
    int i = c + orig;
    float f = (float)(i-500) / 100.0;
    string fname = "%03d" % [i];
    @{"./raytrace.out %s.ppm %lf" % [fname, f]};
    @{"convert %s.ppm %s.jpg" % [fname, fname]};
    @{"rm -f %s.ppm" % [fname]};
  }
}

void main(list args) {
  list my_servers = loadcsv "servers.csv";
  list common = [(file)"raytrace.out"];
  list inputs;

  connect my_servers;

  for (int i = 0; i < 10; i = i + 1) {
    inputs = [[i*100]] + inputs;
  }
 
  list output;
  int render_job = push Render, common, inputs, output;
  wait render_job;

  for (int i = 0; i < length output; i = i + 1) {
    map out = (map)output[i];
    for (int j = 0; j < length (list)out["files"]; j = j + 1) {
      @{"mv %s/%s %s" % [(string)out["root"], 
                         (string)((list)out["files"])[j],
                         (string)((list)out["files"])[j]]};
    }
  }
  
  @{"ffmpeg -i %03d.jpg test.mp4"};
}

\end{lstlisting}

This program runs a raytracer binary (written in C using OpenGL) which renders a 3D image and outputs a PPM (portable pixmap) image on remote machines defined in CSV file.

Here, the primary functionality exhibited is the \verb|@| symbol (the Pigasus \verb|system| command used for running command lines on the shell. This also exhibits  the fact that this program runs sigificantly faster on multiple machines than the case when the images are rendered locally, thus providing a convincing case for the power of Pigasus. 

\subsection{Using Functions}
\begin{lstlisting}[caption=A program that uses Euclid's Algorithm]
job TestGcd(list inputs) {
  int extra = gcd(6, 28);
  @{"echo %d %d %d %d %d %d %d"
    % [(int)inputs[0], (int)inputs[1], (int)inputs[2],
  	   (int)inputs[3], (int)inputs[4], (int)inputs[5], extra]};
}

void main(list args) {
  list server = [["host"=>"localhost",
                  "user"=>"dummy",
                  "password"=>"dummypw"
                 ]];
  connect server;

  list inputs;
  inputs = inputs + [ gcd(102,34), gcd(122,42) ];
  inputs = inputs + [ gcd(32,13), gcd(11,3) ];

  int a = gcd(15, 20);
  int b = gcd(12, 16);
  inputs = inputs + [ a, b ];

  list nil;
  push TestGcd, null, [inputs], nil;
}

int gcd(int m, int n) {
  if ((m mod n) == 0)
    return n;
  else
    return gcd(n, m mod n);
}
\end{lstlisting}

This final example illustrates the use of functions in Pigasus. We adopt the usual C syntax for defining and using functinos, with the exception that there is no need to use function prototypes. To illustrate this, we call a function {\it gcd} within {\it main}, but we only declare it after it.

%$

\section{Language Reference Manual}

\subsection{Introduction}

We present here the reference manual for the Pigasus programming 
language. Pigasus is designed to facilitate the process of distributing executable binaries or scripts to multiple machines over an arbitrary network for parallel execution as well as easily providing the input to and retrieving the output from these concurrently running tasks.

\subsubsection{Objectives}

The main objective of Pigasus is to greatly simplify the process of establishing
network connections and quickly transmitting data between the \emph{host}, the
user's primary machine from which the Pigasus program is being run, and the
\emph{remote server} nodes, which are the machines in the network cluster running the individual tasks. With this goal in mind, Pigasus' language constructs will revolve around this, and other capabilities such as advanced data processing, mathematical functions will not be supported. However, Pigasus will also be able to closely interact with the shell, so that if the aforementioned capabilities are needed, the user is free to provide binaries or scripts (written in other languages) and ``plug them in'' to their Pigasus program.

\subsubsection{Types}

The Pigasus language will be typed. In addition to common types such as
\verb|int|, \verb|float|, \verb|string| which are present in many
general-purpose languages, Pigasus will also include types designed to
facilitate the act of establishing network connections and transmitting data
(i.e. \verb|file|). These types will be simplified so that users can quickly
specify remote servers and communicate with them.

\subsubsection{Compiled}

Pigasus is a compiled language. When source code is provided to the Pigasus
compiler, the compiler will translate the program into an intermediate
representation (namely, C++) which will then be compiled into native code using
a common C++ compiler such as G++.

\subsubsection{Imperative}

To reduce the learning curve for Pigasus, the language will be imperative and similar in structure to C/C++. 

\subsubsection{And Finally...}

Now that a brief overview of the main characteristics of the language has been provided, we can proceed to describe the language specification in detail. The Section \ref{sec:future_work} lists language features which we may eventually add to Pigasus in the future.

\subsection{Lexical Conventions}

There will be five kinds of tokens: identifiers, keywords, constants, expression operators and other separators. Whitespace must be used to separate tokens, but are otherwise inconsequential. An important note is that Pigasus is entirely case-sensitive. We will also follow the ``leftmost-longest'' policy for tokenization, whereby each token is the longest string of characters that can constitute a token.

\subsubsection{Comments}

Comments in Pigasus will follow the format similar to C++. Multiline comments are delimited by \verb|/*| and \verb|*/|. Single line comments begin with \verb|//| and are terminated by an end-of-line character. 

\subsubsection{Identifiers}

Identifiers are sequences of English alphabet letters, digits and the underscore character, but cannot begin with a digit. Therefore, identifiers will adhere to the following regular expression:
\begin{quote}\begin{verbatim}
[a-zA-Z_][a-zA-Z0-9_]*
\end{verbatim}\end{quote}

\subsubsection{Constants}

Pigasus will support the following types of constants.

\paragraph{Numeric constants}
Numeric constants can be integer constants or float constants. The former would consist of a sequence of digits. The latter is a sequence of digits with a decimal point. Both types can optionally be prefixed by a \verb|+| or \verb|-|, which changes the sign.

\paragraph{String constants}
String constants are sequences of characters delimited by quotation marks. We will use C-like character escaping to denote newlines, tabs, etc. Note however, that Pigasus does not explicitly support character as its own type. The following escaped characters will be supported.
\begin{itemize}
\item \verb|\n|: new lines.
\item \verb|\t|: tab character.
\item \verb|\\|: the backslash character.
\item \verb|\"|: the double quote.
\end{itemize}


\subsubsection{Keywords}

Many of the keywords used in Pigasus for general purpose instructions are adopted from C. The keywords are listed in Table \ref{tab:keywords}.

\begin{table}[ht]
\centering
\begin{tabular}{lp{0.5in}l}
General & & Pigasus-specific \\ \hline
\verb|int|		& & \verb|length| \\
\verb|float|	& & \verb|list| \\
\verb|string|	& & \verb|file| \\
\verb|void|		& & \verb|push| \\
\verb|null|		& & \verb|wait| \\
\verb|return|	& & \verb|loadcsv| \\
\verb|break|	& & \verb|job| \\
\verb|continue|& & \verb|map| \\
\verb|if|		& & \verb|waitall| \\
\verb|else|		& & \verb|print| \\
\verb|for|		& & \verb|connect| \\
\verb|do|		& & \verb|mod|\\
\verb|while| 	& & \\
          	& & \\
 	        & & \\
		& & \\
\end{tabular}	
\caption{Supported keywords.}
\label{tab:keywords}
\end{table}

\subsection{Conversions}

It is often the case that you way wish to apply an operator to operand(s) of types not usually supported by the operator. Pigasus requires that the programmer explicitly cast all values to the correct type before using them as an operand to an operator requiring that type. That is, there will be no automatic casting. To cast a value to a specific type, see the casting operator in Section \ref{sec:casting_operator}. The rules for conversions between types will be given here. Please beware of overflowing numerical values (i.e. integers and floats), as it will cause incorrect values to be returned. Please see Section \ref{sec:types} for details regarding the types.

\subsubsection{String and Integer}
\label{sec:stringandinteger}

To cast a string to an integer, the leftmost longest substring of the given string consisting of only digits (possibly led by a ``-'' symbol) will be returned as an integer. If the string does not contain a viable integer, then 0 will be returned. More specifically, this will be implemented using the C \verb|sscanf| function, that is, the conversion will be equivalent to the following C++ function:
\begin{quote}\begin{verbatim}
int StringToInteger(string str) {
  int x = 0;
  sscanf(str.c_str(), "%d", &x);
  return x;
}
\end{verbatim}\end{quote}

Casting a integer to a string is straightforward: the integer becomes a string consisting of the same digits and possibly the negative sign.

\subsubsection{String and Floating Point Number}

Given a string to cast to a float, the leftmost longest substring consisting of only digits, possibly led by a ``-'' symbol, consisting of a single decimal point, will be returned as a float. If the string does not contain a viable float, then 0.0 will be returned. The implementation will be similar to what is described in \ref{sec:stringandinteger}.

Casting from a float to a string is done as follows. The float will be converted to its string representation, including a possible negative sign and up to 10 decimal places.


\subsubsection{String and File}

To specify a file in Pigasus, the string filename needs to be cast to a \verb|file| type. That is, consider the following Pigasus code:
\begin{quote}\begin{verbatim}
file f = (file)"test.txt";
\end{verbatim}\end{quote}
This means that the value of \verb|f| is the file \verb|test.txt| in the working directory.

If a file is cast to a string, then only the filename is returned. So, take \verb|f| from above, then consider the following Pigasus code:
\begin{quote}\begin{verbatim}
string s = (string)f;
\end{verbatim}\end{quote}
Then \verb|s| will contain the string ``test.txt''.

\subsubsection{Integer and Floating Point Number}
When an integer is cast to a float, Returns a float with the same numeric value as the integer.

For the reverse, the float will be rounded to the nearest integer.


\subsection{Types}
\label{sec:types}

Pigasus supports 6 native types. They are as follows.

\subsubsection{Integers}
Declared as \verb|int|. These are 32-bit signed integers. Pigasus does not distinguish between signed and unsigned.

\subsubsection{Floating Point Numbers}
Declared as \verb|float|. These are 64-bit floating point numbers (equivalent to C/C++/Java \verb|double|).

\subsubsection{Strings}
Declared as \verb|string|. These are sequences of characters of arbitrary length.


\subsubsection{Lists}
Declared as \verb|list|. Pigasus does not have arrays in the same sense as C/C++/Java. Instead, list structures are used, which an be a list of any mix of natively-supported Pigasus types. Therefore a single list can contain strings, integers, other lists, etc.

\subsubsection{Associated Arrays / Maps}
Declared as \verb|map|. These structures map a string to values of any Pigasus native type. Access time will be $O(\lg n)$ (they will be implemented as C++ maps).

\subsubsection{Files}
Declared as \verb|file|. Files point to a file in either the host or remote machine (depending on whether they are used inside a \emph{job} or not). Currently, Pigasus does not support file input/output, so it is impossible to manually create files (unless you use the shell via Pigasus) or to read from and write to files. Therefore, the main purpose of \verb|file| is to identify files to be sent across the network.

\subsection{Expressions}
Pigasus will have C-style expressions. An expression is a list of ``;'' delimited \emph{statements}. expressions have a value and can appear on the right hand side of an assignment. The precedence of operators is the same as that of C. \verb|+| and \verb|*| associate left to right, and \verb|*| has a higher precedence.

As in C, the order of evaluations of expressions in an argument list is undefined and the programmer should not rely on a particular order

\subsubsection{Primary Expressions}
%NOTE: really?
Primary expressions consist of function calls and group left to right.

\subsubsection{Constant}
Constants include string, float or integer.

\subsubsection{Parenthesized expressions}
The value of a parenthesized expression, denoted by \verb|(expression)| is the same as the expression without the parentheses.
 
\subsubsection{Primary-expression[expression]}
In this type of expression, the square brackets denote subscripting. the \verb|Primary-expression| should evaluate to the type of \verb|list| or \verb|map|.

\subsubsection{Primary-expression(expression-list)}
This type of expressions primarily denote function calls. the
\verb|expression-list| is a (possibly empty) list of comma separated
\emph{parameters} to the function. The type of this expression is the same as
the type of the value returned by the function. For passing parameters, Pigasus
will employ the same policy as Java. That is, basic types such as
\verb|int, float| will be passed by value. For 
\verb|string, list, map, file|, a reference will be passed.

\subsubsection{Unary Operators}

\paragraph{- operator}
\begin{quote}\begin{verbatim}
-expression
\end{verbatim}\end{quote}

The result of this will be the negative of the expression of the same type, provided that the expresion is an \verb|int| or \verb|float|. If \verb|expression| is of a different type, the syntax is undefined (possibly syntax error).

\paragraph{+ operator}
\begin{quote}\begin{verbatim}
+expression
\end{verbatim}\end{quote}

This operator returns the value of expression. This operator has no utility, except to maintain readability: some users may find it helpful to view positive numbers as explicitly stated.

\paragraph{! operator}
\begin{quote}\begin{verbatim}
!expression
\end{verbatim}\end{quote}

The result will be the logical inverse of the expression, provided that the expression is of type \verb|int|.

\subsubsection{Multiplicative Operators}

\paragraph{* operator}
\begin{quote}\begin{verbatim}
expression * expression
\end{verbatim}\end{quote}

The binary operator \emph{*} represents multiplication, hence both expressions must be of type \verb|float| or \verb|int|. The result will always be the more precise type of the two expressions (i.e. if either type is \verb|float|, then the return type will be \verb|float|).

\paragraph{/ operator}
\begin{quote}\begin{verbatim}
expression / expression
\end{verbatim}\end{quote}

The binary operator \emph{/} represents division, hence both expressions must be of type \verb|float| or \verb|int|. If the divisor is 0 (or 0.0 for floats), then this will cause a run-time (division-by-zero) error.

\subsubsection{The \% Operator}

The \% operator is a binary operator of the form \emph{expression \% expression}. If both expressions are numeric (i.e. \verb|float| or \verb|int|), then the operator is to be interpreted as a modulus operator. The result will be the modulus and will be of the same type as the more precise of the two expressions.

If the first expression is a string, then we use this operator as a \verb|sprintf()|-like operator (similar to the \% operator used in Python). That is, if the left expression is a string, then the right expression is to be a list of variables which will be substituted into the string at run-time. For instance, given the following Pigasus string:
\begin{quote}\begin{verbatim}
"Hello %s, how are you %s?" % ["Alice", "Today"];
\end{verbatim}\end{quote}
This is equivalent to the string stored in the variable \verb|str| by the C function:
\begin{quote}\begin{verbatim}
sprintf(str, "Hello %s, how are you %s?", "Alice", "Today");
\end{verbatim}\end{quote}

\paragraph{Format Specifiers}

Here is a list of the supported format specifiers (character strings
beginning with a \%). 
\begin{description}
\item[\%d] Decimal number. An optional parameter can be used in between the \%
symbol and ``dd'' to specify how the output may look. The same parameters as
those accepted by C's format specifier for integers (also ``\%d'') are accepted
by Pigasus.

\item[\%s] String. 

\item[\%lf] Floating point number. Also accepts a parameter which can specify the number of decimal places to show, etc. The same parameters as those accepted by C's format specifier for doubles (``\%lf'') are accepted by Pigasus.
\end{description}

\subsubsection{Additive Operators}
The additive operators \verb|+| and \verb|-| are the same as C. They group left to right.

\paragraph{expression+expression}
The result is the sum of the two expressions. In case of different types, the result is the type of the more precise operand-type. The \verb|+| operator is also defined for strings which has the meaning of concatenation. The result is a \emph{new} string object which is the concatenation of both the strings

\subsubsection{Relational Operators}
These are the usual relational operators:
\begin{itemize}
\item expression $<$ expression
\item expression $>$ expression
\item expression $>=$ expression
\item expression $<=$ expression
\end{itemize}

The value of the expression is the integer equivalent of the boolean value of the relational operator applied. We use the standard notions as used in C, i.e.\ we return \verb|true| if the mathematical evaluation is a true statement, and \verb|false| otherwise.

\subsubsection{Casting expressions}
\label{sec:casting_operator}
These are of the form:
\begin{quote}\begin{verbatim}
(type) expression
\end{verbatim}\end{quote}
\verb|type| refers to a datatype, such as \verb|int|, \verb|string|,
\verb|file|, etc. \verb|expression| refers to some expression that will be one
type that one wants in a different type. For example:
\begin{quote}\begin{verbatim}
(float)5 / (float)2 = 2.5
\end{verbatim}\end{quote}
Even though \verb|5 / 2 = 2|. 

\subsubsection{The Length Expression}
These are of the form:
\begin{quote}\begin{verbatim}
length expression;
\end{verbatim}\end{quote}
Where \verb|expression| must evaluate to a string, list or map. For a string, the \verb|length| expression returns the number of characters in the string as an integer. For a list or map, it returns the number of items as an integer. 

\subsubsection{The Load-CSV Expression}
These are of the form 
\begin{quote}\begin{verbatim}
loadcsv string-expression;
\end{verbatim}\end{quote}
Where \verb|string-expression| is an expression that evaluates to a string. The string is expected to be the location (i.e. path and filename) of a CSV file which contains data regarding the specification of servers. The \verb|loadcsv| expression returns a list of maps which conform to the format needed by the \verb|connect| statement.

\subsection{Declarations}
Declarations are used within function definitions to specify how Pigasus will interpret each identifier.
\begin{quote}\begin{verbatim}
type_specifier init_declarator_list ';'
\end{verbatim}\end{quote}

This is the syntax used to declare variables. The syntax is identical to C.

\begin{quote}\begin{verbatim}
init_declarator_list
  : init_declarator
  | init_declarator_list ',' init_declarator
  ;
\end{verbatim}\end{quote}

This syntax shows how to declare one or more variables in a statement. For
example, \verb|int a;| is allowed, as is \verb|int a,b,c;|. We now describe the
details of which types of variables can be defined.

\subsubsection {Type specifiers}

Type specifiers define the type of the identifier being declared. Each identifier \emph{must} be declared before its first use.
\begin{itemize}

\item \verb|int|
\item \verb|float|
\item \verb|string|
\item \verb|list|
\item \verb|file|
\item \verb|map|

\end{itemize}

\subsubsection {Declarators and Declarator-lists}

A declarator-list is a comma-separated sequence of (possibly initialized) declaration of variables.
These have the following syntax 

\begin{quote}\begin{verbatim}
init_declarator_list:
         declarator
         declarator , init_declarator_list
\end{verbatim}\end{quote}

\subsubsection{Declarators}
Declarators have the syntax:

\begin{quote}\begin{verbatim}
declarator:
       identifier
\end{verbatim}\end{quote}

When a declarator appears in an expression, it yields an object of the indicated type named by its identifier. Each declarator can contain only one identifier; it is this identifier that is declared.

\subsubsection{General Type Declarations}

Common types \verb|string, int, float| are declared the same way it is
done in C++. That is, they can be declared as follows:
\begin{quote}\begin{verbatim}
string a = "hello";
int b = -10;
int c;
float d = -5.0;
\end{verbatim}\end{quote}

\subsubsection {List Declarations}

A new list can be created with the following code:
\begin{quote}\begin{verbatim}
list my_list = ["C", "Java"];
\end{verbatim}\end{quote}
Lists are special in the sense that they can hold data of any type. The given
example declares a list \verb|my_list| of length 2 containing the strings
\verb|"C"| and \verb|"Java"|.

\subsubsection {File Declarations}

Files in languages like C and C++ are usually declared using file pointers and
opening a file. However, Pigasus does not support file I/O and therefore does
not give users the option to open the file. The ability to specify files is only
needed to identify them for transmission over the network.

A \verb|file| object is declared by casting a string to a file. The main
difference is that declaring a file object does not create any file. Since the
primary role of files in Pigasus is just as objects to be sent across the
network, the only operation supported for files is typecasting a string
(containing the file name) into a file. This step is necessary for Pigasus to be
able to send files across the network.

For instance, files are declared as follows:
\begin{quote}\begin{verbatim}
file f = (file)"helloworld.txt";
\end{verbatim}\end{quote}

\subsubsection {Job Declarations}

A job declaration has the following form:
\begin{quote}\begin{verbatim}
job_definition
  : job name '(' parameter_declaration ')' compound_statement
  ;
\end{verbatim}\end{quote}

For example, here is a sample Job declaration:
\begin{quote}\begin{verbatim}
job RunHello(list inputs) { 
  @{"./hello"};
}
\end{verbatim}\end{quote}
Job definitions can appear wherever a function definition can appear. Thus a Pigasus translation unit consists of function declarations and job declarations. 
 
\subsubsection {Map Declarations}
Maps are declared in the same manner as lists. The difference is in the initialization part, where we specify the key value pairs in the initial map.
Here is the syntax:

\begin{quote}\begin{verbatim}
map my_map = ["teamname" => "hogzilla", "compiler" => "Pigasus"]
\end{verbatim}\end{quote}
Note the use of the \verb|=>| operator to map a key to a value.

To associate a new key to a value, simply assign the value to the key as
follows. For instance:
\begin{quote}\begin{verbatim}
my_map["jordan"] = "iscool";
\end{verbatim}\end{quote}

\subsection{Statements}
Statements resemble C statements with all the usual constucts for compound statements like looping and conditional statements

\subsubsection{Expression Statement}
Most statements are just semicolon delimited expressions 
\begin{quote}\begin{verbatim}
expression;
\end{verbatim}\end{quote}

\subsubsection{Compound Statements}
These can be several statements where a single statement is expected 
\begin{quote}\begin{verbatim}
compound-statement:
               {statement-list}
statement-list:
               statement
               statement statement-list
\end{verbatim}\end{quote}

\subsubsection{Push Statements}
This is a Pigasus special statement. This is of the form
\begin{quote}\begin{verbatim}
push job-expression, file-expression, input-expression, 
     output-expression 
\end{verbatim}\end{quote}

This statement is the primary way in which programmers can push jobs to servers. \verb|job-expression| is an expression which evaluates to a Job object, \verb|file-expression| is an expression evaluating to a list containing binary executables that need to be sent over to the remote machine to be executed. \verb|input-expression| is a list of objects (like strings or file) which needs to be sent as inputs to the program. \verb|output-expression| is an expression which evaluates to a list to which all the output files generated by the program is copied. It cannot be null.

\subsubsection{Wait Statements}
These statements are used to create a blocking wait over a Pigasus distributed Job. Execution is suspended till the appropriate job is completed on the server and results are available. The following are the types of main

\paragraph{Single Wait Statements}
These are of the form 
\begin{quote}\begin{verbatim}
wait id;
\end{verbatim}\end{quote}

Here \verb|id| is the integer id returned by the \verb|push| statements. Execution is suspended until the job represented by \verb|id| is completed.

\paragraph{Wait-All Statements}

This is of the form 
\begin{quote}\begin{verbatim}
waitall;
\end{verbatim}\end{quote}

The effect of this statement is to suspend execution of the Pigasus program until \emph{all} the jobs sent out via \verb|push| are completed


\subsubsection{@ Statements}
These have the form:
\begin{quote}\begin{verbatim}
@{ expression };
\end{verbatim}\end{quote}
Where \verb|expression| must evaluate to a string.

The \verb|expression| is a string containing a shell command. This statement is
meant to allow the user quick access to the system. Note that if the @ statement
is used by the \verb|main| function, then the shell command will be executed on
the host. If the @ statement is used within a \verb|job|, then the shell command
will be executed remotely. This is true even if the @ statement is contained
within a function. That is, suppose function \verb|f()| contains an @ statement.
Then if a job calls \verb|f()|, the statement will be executed remotely. If
\verb|main| calls \verb|f()|, then the statement will be executed on the host.

\subsubsection{Conditional Statements}
These are the \verb|if-else| statements:
\begin{quote}\begin{verbatim}
if ( expression ) statement
if ( expression ) statement else statement
\end{verbatim}\end{quote}
As usual \verb|expression| is evaluated and if it is non-zero, the corresponding statement is executed. If the \verb|expression| is zero and an \verb|else| is provided, it will be executed. each \verb|else| is matched to the last \verb|if| which is unmatched

\subsubsection{While Statements}
These have the form:
\begin{quote}\begin{verbatim}while ( expression ) statement\end{verbatim}\end{quote}
The \verb|statement| is executed repeatedly as long \verb|expression| is non-zero. In particular, if \verb|expression| is zero on the outset, \verb|statement| is never executed

\subsubsection{Do-While Statements}
The \verb|do-while| statements have the following form:
\begin{quote}\begin{verbatim}
do statement while ( expression ) ;
\end{verbatim}\end{quote}
As in the case of a \verb|while| statement, \verb|statement| is executed repeatedly as long as \verb|expression| evaluates to a non-zero value, however, the main difference is that in this construct, \\ \verb|statement| is executed at least once, this means that the test takes place \emph{after} each execution of the \verb|statement| 
\subsubsection{For Statement}
\verb|for| statements have the following form
\begin{quote}
\begin{verbatim}
for ( optional-init-expr ; optional-cond-expr ; optional-post-expr )
  statement
\end{verbatim}\end{quote}

The for loop is a handy way to keep all the loop variables in a convenient location.
each expression inside a for loop is optional. \verb|optional-init-expr| is executed \emph{once} before the loop is entered, the \verb|optional-cond-expr| is a conditional expression which is tested before evaluating the body and the  \verb|optional-post-expr| is evaluated after each time the body is evaluated.

For example, the for loop can be used to loop 10 times in the following way:
\begin{quote}
\begin{verbatim}
for ( int i=0; i<10; i=i+1 ){
    statement;
}
\end{verbatim}\end{quote}

Note that the value of an empty \verb|optional-cond-expr| is taken to be non-zero.

As another example, an infinite loop can be written simply as 
\begin{quote}
\begin{verbatim}
for (;;){
    statement;
}
\end{verbatim}\end{quote}

\subsubsection{Break Statements}
These are of the form
\begin{quote}
\begin{verbatim}
break;
\end{verbatim}\end{quote}

A break statement can appear only in a looping construct like a for loop, while loop or a do-while loop. When a break statement is encountered, an immediate exit from the innermost exit from the innermost loop containing the statement is effected. Normal execution proceeds with the next statement following the loop. Break statements can be used to exit prematurely from a loop 

\subsubsection{Continue Statements}
These are of the form 
\begin{quote}
\begin{verbatim}
continue;
\end{verbatim}\end{quote}

These statements can appear wherever a break statement can appear. It only affects the innermost loop which contains the statement. The effect of the continue statement is that the current iteration of the loop is terminated and control proceeds to the next iteration. It is as the body of the loop has finished executing for this iteration.

\subsubsection{Return Statements}
This is of the form 
\begin{quote}
\begin{verbatim}
return;
return expression;
\end{verbatim}\end{quote}

Return statements are used to return a value back to the calling function.
A return statement is optional for a function. If none is provided, control automatically returns to the calling function after the last statement in the function is executed.

 The \verb|return;| statement causes control to return immediately to the calling function. 

the \verb|return expression;| evaluates the expression and returns the result to the calling function

\subsubsection{Null Statements}

These are of the form

\begin{quote}
\begin{verbatim}
;
\end{verbatim}\end{quote}

It is primarily used to provide an empty statement in looping constructs like for loops. It can be used in any place which expects a statement.

\subsection{Future Work}
\label{sec:future_work}

\subsubsection{List Manipulation}

The list type currently only supports assignment, concatenation and accessing
the elements. Ideally, simple operations such as removing elements, getting
subsequences (possibly using the Python slice notation) may be implemented in
the future.

\subsubsection{Improve Casting}

The initial release of Pigasus will require explicit casting when attempting to
apply operands of incorrect types to operators. Future release could detect the
required types and cast automatically.

Another aspect worth improving is the ability to cast between Pigasus-specific
types. That is, currently it is possible to cast between the general types such
as string, int, etc. as well as file. However, there is no way to cast between
map and list.

\subsubsection{Boolean Expressions for Wait Statements}

Statements \verb|wait| and \verb|post| currently require an integer identifer,
but future releases would ideally support logical expressions. For example:
\begin{quote}\begin{verbatim}
post (a || (b && c)) {
  ...
}  
\end{verbatim}\end{quote}

\subsubsection{Key Events}
\label{sec:key_events}

Currently, all remote tasks must be completely scripted. As a result,
interactive binaries (i.e. those that require input from standard-input during
the program's execution) cannot be handled gracefully. Adding the ability to
transmit key-events would allow users to run remote jobs as if they were
physically sitting in front of the machine.

\subsubsection{Mouse Events}

Similar to Section \ref{sec:key_events}. If mouse events can be automated
along with key events, then it would greatly expand the number of kinds of jobs
that can be automated and distributed.

\subsubsection{Support File Input/Output}

Pigasus does not currently support file input and output as it is currently
focused on distributing jobs. Ideally, future versions would allow users to
directly manipulate files and data from Pigasus.

\subsubsection{Alerts For Completed Jobs}

For jobs that have exceedingly long execution times, it may be useful for some
users to be notified when they are complete. Therefore, a feature that would
allow Pigasus to send an alert by email or SMS could be beneficial.

\subsubsection{Ability to Resume Pigasus Programs}

The Pigasus program needs to be running in order to manage the distributed jobs
and fetch output. However, if the host machine is turned off or the program is
otherwise terminated, it is impossible to resume the task despite the fact that
remote jobs may still run to completion. We hope to eventually implement the
feature where Pigasus programs may be terminated and run at a future time and
resume where they left off.

\subsection{Grammar}
Here is the YACC compatible grammar for Pigasus. It is partly based on the ANSI
C grammar provided by \cite{degener:ansi}.

\begin{verbatim}
translation_unit          : translation_unit function_definition 
                          | translation_unit job_definition      
                          |
                          ;
                                      
job_definition            : JOB IDENTIFIER '(' LIST IDENTIFIER ')' 
                              compound_statement
                          ;

declaration               : primary_declaration
                          | function_definition
                          ;

primary_declaration       : type_specifier identifier_list
                          ;

identifier_list           : init_statement        
                          | identifier_list ',' init_statement 
                          ;
                    
init_statement            : IDENTIFIER
                          | IDENTIFIER '=' assignment_expression
                          | IDENTIFIER '=' push_statement 
                          ;
                    
list_initializer          : '[' list_elements ']'
                          ;
                    
map_initializer           : '[' map_element_list ']'
                          ;

list_elements             : element                     
                          | element ',' list_elements   
                          ;
                    
map_element_list          : map_element                 
                          | map_element ',' map_element_list
                          ;
                    
map_element               : IDENTIFIER MAPS_TO assignment_expression     
                          | STRING_LITERAL MAPS_TO assignment_expression 
                          ; 
                    
element                   : assignment_expression
                          ;
                    
function_definition       : type_specifier IDENTIFIER '(' formal_id_list ')' 
                              compound_statement
                          | type_specifier IDENTIFIER '(' ')' compound_statement
                          | VOID MAIN '(' LIST IDENTIFIER ')' 
                              compound_statement_main
                          | VOID MAIN '(' ')' compound_statement_main
                          ;
                        
                      
formal_id_list            : type_specifier IDENTIFIER
                          | formal_id_list ',' type_specifier IDENTIFIER
                          ;

type_specifier            : VOID    
                          | INT     
                          | FLOAT   
                          | STRING  
                          | LIST    
                          | MAP     
                          | FILES   
                          ;

statement_list            : statement
                          | statement_list statement
                          ;


statement                 : matched_statement
                          | open_statement
                          | iteration_statement
                          ;
                                             
matched_statement         : compound_statement
                          | push_statement
                          | expression_statement
                          | jump_statement
                          | wait_statement
                          | PRINT expression ';'        
                          | IF '(' expression ')' matched_statement
                              ELSE matched_statement
                          ;
                                        
open_statement            : IF '(' expression ')' statement
                          | IF '(' expression ')' matched_statement 
                            ELSE open_statement 
                          ;                           
                     
compound_statement        : '{' '}'
                          | '{' statement_list '}'
                          ;
                    
compound_statement_main   : '{' statement_list '}'  
                          ;


expression_statement      : ';'               
                          | expression ';'  
                          | declaration ';'
                          ;
    
iteration_statement       : WHILE '(' expression ')' statement
                          | DO statement WHILE '(' expression ')' ';'
                          | FOR '(' expression_statement  expression_statement ')'
                             statement
                          | FOR '(' expression_statement  expression_statement 
                            expression ')' statement
                          ;

jump_statement            : CONTINUE ';' 
                          | BREAK ';'    
                          | RETURN ';'   
                          | RETURN expression ';' 
                          ;
               
push_statement            : PUSH assignment_expression ',' assignment_expression ','
                            assignment_expression ',' IDENTIFIER
                          ;
                  
                  
wait_statement            : WAIT IDENTIFIER ';' 
                          | WAITALL ';'         
                          ;
                                    
primary_expression        : IDENTIFIER        
                          | CONSTANT          
                          | STRING_LITERAL    
                          | NULLS             
                          | '(' expression ')'
                          | list_initializer
                          | map_initializer
                          ;
                    
postfix_expression        : primary_expression                                      
                          | postfix_expression '[' expression ']'                   
                          | postfix_expression '(' ')'                              
                          | postfix_expression '(' argument_expression_list ')'     
                          ;
                          
argument_expression_list  : assignment_expression
                          | argument_expression_list ',' assignment_expression    
                          ; 
                          
unary_expression          : postfix_expression 
                          | unary_operator cast_expression 
                          | LOADCSV cast_expression        
                          | LENGTH cast_expression         
                          | CONNECT cast_expression          
                          | system_expression               
                          ;

system_expression         : '@' '{' expression '}'
                          ;
                    
unary_operator            : '+'
                          | '-'
                          | '!'
                          ;
                    
cast_expression           : unary_expression
                          | '(' INT ')' cast_expression 
                          | '(' FLOAT ')' cast_expression 
                          | '(' MAP ')' cast_expression 
                          | '(' LIST ')' cast_expression 
                          | '(' FILES ')' cast_expression 
                          | '(' STRING ')' cast_expression 
                          ;


multiplicative_expression : cast_expression
                          | multiplicative_expression '*' cast_expression 
                          | multiplicative_expression '/' cast_expression 
                          | multiplicative_expression '%' cast_expression 
                          | multiplicative_expression MOD cast_expression 
                          ;

additive_expression       : multiplicative_expression
                          | additive_expression '+' multiplicative_expression 
                          | additive_expression '-' multiplicative_expression 
                          ;

relational_expression     : additive_expression
                          | relational_expression '<' additive_expression     
                          | relational_expression '>' additive_expression     
                          | relational_expression LE_OP additive_expression   
                          | relational_expression GE_OP additive_expression   
                          ;

equality_expression       : relational_expression
                          | equality_expression EQ_OP relational_expression   
                          | equality_expression NE_OP relational_expression   
                          ;

logical_and_expression    : equality_expression
                          | logical_and_expression AND_OP equality_expression 
                          ;

logical_or_expression     : logical_and_expression
                          | logical_or_expression OR_OP logical_and_expression
                          ;
                        
assignment_expression     : unary_expression '=' assignment_expression  
                          | logical_or_expression       
                          ;
                          
                          
expression                : assignment_expression
                          | expression ',' assignment_expression  
                          ;

\end{verbatim}

\section{Project plan}% (to be written by the project manager)

%    * State what process used was used to develop the language and its translator.
%    * State the roles and responsibilities of each team member.
%    * Include the implementation style sheet used by the team.
%    * Show the timeline of what was done when.
%    * Include your project log

This section is written by the project manager, John Zhang.

\subsection{Language and Translator Development}

Our overall approach to the development of the language and translator was
divided into three stages: first, assembling our group and deciding on a
language focus, second, deciding upon language specifications and necessary
functionality, and finally, implementation, testing and presentation. Of course,
these stages were not disjoint.

We were fortunate to have been able to select our team mates early and thus 
begin work right away. Almost immediately after our team was founded, we began 
to meet regularly (at least once per week) to decide on the focus of our 
language, and subsequently, what language features would be necessary to 
implement the desired functionality. During this time, we also selected team 
roles, and decided on a team name and language name.

In the weeks after, we began meeting with increased frequency to decide on 
the specifications of our language as well as other implementation details.

\subsubsection{Specifications}

In the planning process, we decided upon the core objectives of our language.
A Pigasus programmer should be able to accomplish the following with relative 
ease:
\begin{itemize}
\item Send a list of files or data to a remote machine.
\item Execute or otherwise manipulate the files on the remote machine.
\item Retrieve files produced or modified by the execution script on the remote
machine.
\item Specify information regarding servers and files with ease in the Pigasus
code.
\end{itemize}

We regularly held discussions as a group over a whiteboard, especially when 
deciding on the functionality that would be needed by the user (Figure 
\ref{fig:plt_mar26}). The planning and specification phase culminated in the 
language whitepaper, reference manual and tutorial.

\begin{figure}[ht]
\begin{center}
\epsfig{figure=PLT_Mar26.eps, width=5in}
\end{center}
\caption{Photo of whiteboard during early meetings.}
\label{fig:plt_mar26}
\end{figure}

\subsubsection{Implementation}
\label{sec:implementation}

Once we had decided on a language specification and submitted our documentation,
we began to work on the implementation of the language in ernest. Of course,
before this could begin, a number of key decisions had to be made as a group.

\begin{enumerate}

\item {\bf Platform}. In addition to the development platform, we had to
envision what requirements would have to be asked of the user. Linux 
(or any Unix-based OS) was chosen as the operating system of Pigasus as 
our target audience of students and researchers were most likely to have access
to networked Linux machines running SSH (e.g.\ CLIC). SSH was chosen as the
means for transmitting files between the host and remote machines for its 
popularity, security and ease-of-use. It is commonly pre-installed on Linux 
machines.

\item {\bf Language front-end}. We had chosen to model our language on C to 
reduce the learning curve for many potential users. Also, the grammatical 
resemblence between Pigasus and C provided us ample resources and sample 
grammars to build upon. It also naturally led us to Bison and Lex. 

\item {\bf Language back-end}. The back-end was built primarily using C++ with 
some Bash and Expect scripts. C++ was chosen due to our familiarity with the 
language, its excellent integration with the system and shell, and also our 
desire to use the opportunity to improve our knowledge of the language.

\end{enumerate}

A division of labor was necessary so that everybody was able to contribute 
while minimizing the common problems that might occur in communicating ideas 
between disparate focuses within the group. To achieve this, we decided to 
divide into two sub-groups: two members would focus on implementing the 
back-end, and two members would focus on the front-end. Section \ref{sec:roles}
describes team member roles in greater detail.

This division allowed development of the front-end and back-end to proceed in 
parallel, with regular integration and testing. We continued to contribute code
individually while meeting regularly for group coding sessions which allowed us
to communicate with one another and provided a chance for the front-end and
back-end to decide on the interface.

Near the conclusion of the project term, we began meeting with increasing
frequency as we worked to integrate the front-end and back-end and gradually
shift our focus to testing.

\subsection{Team Member Roles}
\label{sec:roles}

The team members and their responsibilities are listed as follows. In addition
to the individual tasks listed, every team member also contributed to the
overall specification of the language and to integration and testing.

It should also be noted that we encountered a small challenge midway through 
our project as one of our team members chose to leave the course. His 
responsibilities as the system integrator, were undertaken by the entire team.

\begin{itemize}

\item John Zhang (project manager).

The project manager was mainly responsible for setting the pace of the project,
organizing meetings and setting the agenda. The project manager also helped to
design the high-level architecture of the language and translator, as well as
help to design and implement the backend.

\item Jordan Rupprecht (system architect).

The system architect was responsible for many design decisions regarding the
back-end, especially the method of distributing files and executing them
remotely. The architect was also responsible for the selection of many of the 
tools used, as well as help to implement the back-end.

\item Sharath Gururaj (language guru).

The language guru was responsible for many design decisions in the front-end.
This included changes in the language specifications that needed to be made, as
well as the selection of tools needed to implement the front-end. The language
guru also helped to implement the grammar and translation schemes.

\item Philip Tjimos (testing and validation).

The testing and validation person was responsible for writing test cases for the
language, as well as for decisions regarding the testing framework. The testing
and validation person also helped to design and implement the front-end.

\end{itemize}

\subsection{Programming Style}

As our project involved code in several languages, we had to employ a number of
different styles.

\subsubsection{C++}

The vast majority of our code was written using C++. We decided to follow the
Google C++ Style Guide \cite{google_style_guide} (publicly available for
open-source development on Google Code\footnote{http://code.google.com.}).

The Google C++ style greatly improved the modularity and readability of our
code. It was also extremely comprehensive and provided guidelines for good
programming practices. We did our best to follow the style guide as rigorously
as possible, but do to time constraints, our adherence is likely imperfect.
Furthermore, due to time and personnel constraints, we were unable to use 
code reviews.

Some highlights of the Google C++ style guide include:
\begin{itemize}
\item Header files include \verb|#define| guards to prevent multiple inclusion.
\item Lines limited to 80 characters.
\item Use only spaces (2 spaces) instead of tabs.
\item Variable names in lowercase, with different words separated by
underscores.
\item Variable names were selected to be meaningful.
\item Class names and function names are in CamelCase.
\item File names are also in lower case.
\end{itemize}

Clearly the Google style guide is much more comprehensive, but these highlights
were the most frequently used. 

\subsubsection{Scripting}

Our scripts were limited to only a few lines and were written by the system
architect. Since the scripts were primarily used to execute shell commands, no
style guide was deemed necessary.

\subsubsection{Bison / Flex}

Style was similar to specifications for C found in \cite{degener:ansi}. Yacc 
specification followed a soft 80-character limit with all conjunctions
aligned. 

\subsection{Timeline}

For the project timeline, please see Table \ref{tab:timeline}.

\begin{table}[ht]
\begin{center}
\begin{tabular}{|p{1.75in}|p{3.5in}|} \hline \hline
Date (MM/DD/YY) & Accomplishment \\ \hline
01/21/09 -- 01/26/09	&Team formed.	\\ \hline
01/27/09 -- 02/02/09	&Language focus defined. \\ \hline

02/17/09 -- 02/25/09	&Language features defined. Whitepaper produced. \\ \hline

03/03/09 -- 03/09/09	&Began specific outlining of language grammar and syntax.
Research into related language grammars, etc.	\\ \hline

03/10/09 -- 03/23/09	&Formalized specification of language. Began
implementation of front-end and back-end. Especially basic Lex specification and
back-end implementation of basic types.	\\ \hline

03/24/09 -- 03/30/09	&Language reference manual produced. Tutorial produced.	\\ \hline

3/31/2009 -- 04/20/09	&Continued implementation of back-end and front-end. Began
testing of network transmissions and execution.	\\ \hline

04/21/09 -- 04/27/09	&Final presentation created. Continued implementation of
back-end and front-end.	\\ \hline

04/28/09 -- 05/04/09	&Final presentation given. Final and minute adjustments
made to grammar and syntax. More features implemented. Compiler produced.	\\ \hline

05/05/09 -- 05/11/09	&Created more test cases. More testing of tutorial
programs was done. Final report produced. First release version of Pigasus
produced.	\\ \hline
\end{tabular}
\caption{Project timeline.}
\label{tab:timeline}
\end{center}
\end{table}



\subsection{Project Log}

Please refer to the project log in the Appendix.

\section{Language Evolution}% (to be written by the language guru)

%    * Describe how the language evolved during the implementation and what steps were used to try to maintain the good attributes of the original language proposal.
%    * Describe the change management process used by the team as the translator was implemented.

This section was written by Sharath Gururaj.

Our Language was revised many times as the language evolved. Some of the main stages of evolution have been captured in the following figure:

\begin{figure}[htp]\begin{center}
\includegraphics[scale=.75]{Slide1.eps}
\caption{Various stages of our language evolution}
\label{fig:fig1}
\end{center}\end{figure}

\newpage
\subsection{Initial Brainstorming}
Initial Brainstorming: This was the initial stages of language evolution when we met up many times to discuss the application area of our language. One major lesson that we learned early on was the difference between an application area for a \emph{program} and that of a \emph{programming language}. Needless to say, many interesting ideas were put forth and pondered upon.
\paragraph{}
Many ideas in these initial days were dropped because of various reasons like:
\begin{itemize}
\item Very specific application area. i.e problems could best be catered by a single problem  with different inputs. In this case a \emph{software program} would be best -- rather than multiple problems of the same nature (which would actually call for a \emph{programming language} ).
\item Programming language would be too complicated to be implemented in the course of a semester
\item A language for the target application area already exists.
\end{itemize}
Thus, coming up with a good application area required a lot of initial research. From the outset, our goal was to target something that was hard to implement giving the present diverse array of programming languages. The application area of distributed computing fit perfectly with this line of thought because, two of our team members faced the same problem of ditributing applications for one of their courses. It was a well defined application area which did not have easy-to-use solutions. Thus Pigasus was concieved as the programming language meant to fill this niche.
\subsection{Language Features Discussion}

This was arguably the most important stage from the viewpoint of language evolution. Pigasus literally took shape in this series of discussions. Though we had been warned against over-ambition, all of us started suggesting our favourite feature from programming languages we were most familiar with. Of course, Pigasus-Specific features were also discussed and debated a lot.

Some important features which we decided to implement in Pigasus (and looking back, were very useful features to have in Pigasus)

\begin{itemize}
\item The ``\%'' operator for string concatenation
\item The wait and waitall statements
\item declaration of variables throughout the body of a function (like C++ rather than C)

\end{itemize}
\newpage
 Here are some of the features which were decided to be implemented in the final version but were soon realised that they were non-essential and could be moved to ``future work''

\begin{itemize}
\item Support File Input-Output: The abiliy to read and write to files
\item Alerts for completed jobs: Through E-Mail or even SMS
\item Fuller List manipulation APIs: Some features like element deletion, subsequence list creation

\end{itemize}

\subsubsection{Key Language Decisions}
The key language decisions are listed below:
\begin{itemize}
\item Pigasus would be translated to C++: This was based on the fact that C++ was fast, required very little setup from the point of a Pigasus user, and has convenient ssh libraries which could be adapted for our purposes. 
\item C++ would be used for development: The decision was also based the comfort level of the team with C++, and the fact that Bison -- probably the most standardized tool for compiler development uses C++.
\item Pigasus would borrow the best of language features from other languages (while keeping it simple). Thus, we implemented declarations in function body, perl-like string manipulation routines, very convenient list operations. Furthermore, We were concious that developers would be using Pigasus to save time. Not to deal with obscure networking/multithreaded errors. Thus the learning-curve for Pigasus had to be just right to be convincing to people to use Pigasus. Which meant keeping the language simple yet complete for the most common applications. Thus Pigasus borrows from C to a large extent and uses some good features from other languages like perl and Java.

\end{itemize}

\subsection{Preparing the LRM}

The next stage was the preparation of LRM, where we actually put all our ideas into words, and started writing the grammar. At this stage too, the language underwent many revisions -- mainly for consistency issues. For example, we realised we were using the \% operator for both formatting strings and the usual MOD operator which presented an inherent ambiguity in the language. (We later changed the remainder operator to the keyword ``mod'').

\subsection{Coding the grammar -- Build Phase}
In this phase, there were relatively less changes since we had done quite a thorough job in the design phase. In this phase, we realized one more important thing: that the implementation of the distribution code was much more intricate and time-consuming than we initially estimated. Thus, In this stage, we slightly trimmed-down the language in view of the time-frame. 

\subsection{Testing the grammar}
This was a continual phase since testing was integrated with our build phase. We did find constructs which were not supposed to be accepted but were accepted, which resulted in changes to the grammar. But the language itself underwent almost no change in this phase.


\section{Translator architecture}% (to be written by the system architect)

This section was written by Jordan Rupprecht.

%    * Show the architectural block diagram of translator.
%    * Describe the interfaces between the modules.
%    * State which modules were written by which team members.

\begin{figure}[htp]\begin{center}
\includegraphics[scale=0.5]{block.eps}
\caption[Block diagram]{A block diagram of the Pigasus compiler. The input source is lexed and parsed, and the each resulting .cc file is compiled.}
\label{fig:block}
\end{center}\end{figure}

Figure~\ref{fig:block} shows the block diagram for Pigasus. As it indicates, the source pig file is first sent into the lexer and parser. This not only translates the Pigasus code, but also breaks it up so that each job is in a separate file. Thus, PigMain will be compiled into its own program, and each job will be compiled separately into its own executible. When we compile the programs, we only include the necessary files.

\begin{figure}[htp]\begin{center}
\includegraphics[scale=0.5]{arch.eps}
\caption[Backend architecture]{Backend archtecture overview. This illustrates how ``pushing'' a job actually works.}
\label{fig:arch}
\end{center}\end{figure}

Pigasus is actually a fairly straightforward language in terms of syntax, but it
has a heavy backend. An overview is shown in figure~\ref{fig:arch}. At some
point, \verb|PigMain()| will push a job. When it does this, we create a separate
thread called \verb|JobThread|. This thread will then parse the inputs list it
is given and determine how many instances it needs to create; so, for example,
if the inputs list is of length 5, we need to send out 5 instances. Instead of
sending these in a loop, the \verb|JobThread| actually spawns one thread, called
\verb|SendThread|, to do the work for it. Each \verb|SendThread| will create the
remote environment, send the files, and start the job running in the background.
After all the \verb|SendThread|s have been created, the \verb|JobThread| will
iteratively poll each machine to see if it is done. We actually just make the
script on the remote end generate a file called `\verb|done|' when it is
finished, so we check if this file exists. If the instance has finished running,
then the \verb|JobThread| launches a new thread, called \verb|GetThread|, which
retrieves the files and returns the information to the \verb|JobThread|. The
\verb|JobThread| will continue this until every single instance has finished
and the data has been returned.

A final point about the threads: we realized that we could have a scenario 
where too many threads would spawn. For instance, if you have a job with 
10,000 input cases, this would spawn 10,000 \verb|SendThread|s. To counter 
this, we actually implement thread pools, so we limit the number of threads in 
any thread pool to a small, constant number (right now it is 50, but that is 
arbitrary). We do this for the three types of threads we have: 
\verb|JobThread|s, \verb|SendThread|s, and \verb|GetThread|s.

\section{Development environment}% (to be written by the system integrator)

In lieu of a specific person to fill this role, this section was written by 
the entire team.

%    * Software development environment used
%    * Implementation languages and tools used
%    * Libraries used

We developed Pigasus on all three major platforms: Linux (Ubuntu 9.04), Mac
(OS X 10.5), and Windows (XP). However, Windows was only used for parsing--we
do not support the standard Windows environment when actually running Pigasus
code.

For lexing and parsing, we used flex and bison. Since this job was relatively
straightforward, we only needed those two languages. On the backend, almost all
of the work was done in C++, but thereare key components which are done in
scripting languages. Since bash scripting is very good for interacting with the
shell, anytime we need to execute a series of steps, we use a script. One
particular case cropped up, however, where even bash wasn't enough: if the user
gives us a password, there is no way to input this password to ssh from the
command line. Our solution was to use a scripting language called \emph{expect},
which can interact with a program as if you are actually typing. For instance,
we expect the phrase `password: ', and when we see this, we enter the password
(the actual input will be something like `user@host's password: ').

\section{Test plan}% (to be written by the system tester)

%    * Describe the test methodology used used during development.
%    * Show programs used to test your translator.
This section was written by Philip Tjimos.

Throughout the design of Pigasus small test scripts were written to ensure
correctness of both the grammar as well as the backend C++ code. With each
change to the grammar we checked to make sure the intermediate code that was
generated was consistent with our expected output and the function prototypes
of our C++ code. Each production of our grammar has been checked using the
script \verb|pigasus-grammar.sh|. Some regression testing was used as well because
often when a change to the grammar was made it would cause shift/reduce errors
or reduce/reduce errors somewhere else in the grammar.

The script \verb|pigasus-grammar.sh| makes a compiler and then generates sample pigasus
code. This code is then compiled into C++ and compared to sample C++ code that
was pre-written. Using the diff command we were able to determine if any changes
needed to be made to the grammar in order to correspond to the code we were
expecting. The script does this for each production of the grammar.

Testing in this way helped me catch a large amount of typos and small mistakes
that our grammar contained. If a change to the grammar caused a syntax error I
could quickly see which production was causing that error. Also if the output
was incorrect diff would make it simple to see the difference between the two
versions of the code.

For testing the backend we did ad-hoc unit testing using MiniCppUnit. With this
framework we were able to create test cases for our C++ functions to ensure that
they were working as expected. We test pigasus-types, casts, loadcsv,
serialization, and formatstrings. This helped us to ensure that our backend was
working properly and giving expected output by using MiniCppUnit's 
\verb|ASSERT_EQUAL|
commands. This framework was very useful for putting together tests quickly and
it automatically prints out which tests were executed and passed.

Once our front-end and back-end were completed we began integration. Testing for
this involved compiling our sample programs and running them. This helped us
find errors in both the front and back end of our compiler. Some examples were
errors with printing, missing functions, as well as the need to generate header
files for functions.

The programs and scripts used to test both the backend and frontend of the
compiler can be found in section~\ref{sec:test}.

\section{Conclusions}

%    * Lessons learned as a team (to be written by the entire team)
%    * Lessons learned by each team member (written by each team member)
%    * Advice for future teams (written by the entire time)
%    * Suggestions for the instructor on what topics to keep, drop, or add in future courses (written by the entire team)

\subsection{Lessons learned by the team}

Building a compiler with a team was unlike any experience we've had before. It was definitely an exciting project. We could well imagine the thrill and the sense of purpose which pioneers like Kernighan, Thompson, etc would have experienced. We also learned a lot of lessons regarding teamwork and software design in general. 

Here are some of the good things and the not so good things we learned:

\begin{itemize}
\item We didn't have too much trouble organizing team meetings. One good practice that we followed from the very beginning was to have (at least) a weekly team meeting. Initially, This enabled not only to hear each others ideas and think about them early on, but also to keep the upcoming deadlines in focus.
\item We kept our development environment to the bare esesntials. We realized early that Bison-C++ system was powerful enough for our language. This helped us reduce the learning curve for other new tools like ANTLR and focus on language development exclusively.
\item Version control helped us a lot. With three different operating system environments and highly parallelized mode of working, development without version control would be unthinkable. Happily, non-productive time, due to issues like conflicts and merge issues, was minimal.
\item We discovered several interesting quirks in the C programming language. For example, curly braces, could be used interchangeably with \verb|<%,%>| and square brackets can be used with \verb|<:,:>|.
\item While building compilers, the rule of the thumb is -- each task will take twice the amount of time we think it will. We learned valuable lessons about estimation of time required for various tasks. 
\item Looking back, choosing Java as the target and development language would probably have been a better choice. Though C++ offers unparalleled control over low-level issues like memory-management which was useful at times, we would rather have not done it at all. More importantly, Java offers the portability that is a requirement for distributed systems like our own.  
\item Overall, the language turned out to be much much bigger and complex than we initially thought it to be. Cutting down on more features which are not really necessary would probably have resulted in a more comfortable timeline. Sadly, because of this we never got a chance to look at some of the more exciting items in our Future Work section.
\item In software engineering in general and language design in particular, there are dozens of design decisions that occur in every step. Each decision is trade-off between ease-of-implementation or ease-of-use for the end-user. Ultimately, the number of right decisions will decide the success of  a software product. In particular, we were able to appreciate the good decisions which the authors of C have taken which explains the popularity of the language.
\end{itemize}

\subsection{Sharath}

There were definitely some valuable lessons I learned as the language guru:

\begin{itemize}
\item Associate meanings with grammar symbols and stick to it consistently. This helps in code maintenance and future enhancements. In particular, answering questions like ``should PUSH be a statement or an expression'' is easiest if each grammar symbol has a definite meaning and the exact role of the construct is defined.
\item 155 shift/reduce errors need not necessarily mean that there are 155 wrong things with the grammar. Even a couple of wrong placements will cause Bison to complain a lot!
\item The verbose-output of Bison can be intimidating at first but really helpful once you get the hang of it. Though it can complain at the wrong places sometimes.

\item When faced with shift/reduce errors, divide and conquer! The best way to isolate the error is to eliminate productions which cannot be causing the error (for example - by replacing them with a token which cannot cause a shift reduce error). This way you will ultimately isolate the error and can think of alternate productions which will generate the same language.

\item Avoid quick-fixes in favor of a more thorough review before even a small change. (That harmless little production in the middle of ``expression'' will cause big problems later which will be hard to debug).
\end{itemize}

\subsection{Philip}

When developing our grammar we worked a bit backwards. Since our language used similar syntax to C we began with the ANSI-C grammar and modified it accordingly to fit our needs. This probably ending up being more trouble than it was worth. The C grammar is complicated enough and if we started small and worked our way up we probably could've designed a cleaner, smaller grammar. This also made testing tricky but once test scripts were in place they proved to be pretty helpful in finding errors in the grammar.

Working in a group is both rewarding and difficult. We did a good job spliting up tasks and being able to solve problems together was an exciting challenge but managing time is tricky. Our project manager did a good job though making sure we met when we needed to and I think we had a good group chemistry. At first we seemed to disagree on exactly what we wanted pigasus to look like and do, but as the project went on these disagreements seemed to fade away.

Overall, I think I learned a large amount of information about using Bison, Flex, as well as language and grammar structure. Since I worked mainly on the front-end of the compiler I didn't have to delve much into C++ code other than for writing backend test code. Bison and Flex can both be intimidating especially if you're using them for the first time. Getting rid of shift/reduce and reduce/reduce errors was an extremely frustrating experience but it all paid off once the grammar began working as expected.

\subsection{John}

The need for multithreading and the need for heaving network communication
provided some of the key challenges to the development of Pigasus. Developing
programs that perform network operations and developing programs that are
multithreaded are individually known to be difficult, so naturally involving
both compounded the difficulty for both development and testing. This was due to
the unpredictable nature of some of the bugs, and the difficulty of debugging
problems that occurred on remote machines which you are not in control of (i.e.\
that we did not have root access to).

Working as a project manager also provided a most interesting, rewarding and of
course challenging experience. Arranging meeting times that suited the schedules
of several busy students was difficult at times, but ultimately manageable with
a little bit of flexibility. Another responsibility of the project manager was
to set the agenda for our meetings. Setting ``soft'' goals and deadlines 
in addition to the deadlines given in class also helped encourage progress. It
also inevitably lead to many late nights. 

Helping to design the back-end of a multi-threaded program also proved to be a
rewarding experience, particularly since this opportunity does not come along
often to many student programmers (since most programming assignments can be
done in a single-threaded program). Our usage of the C++ language as well as the
required tight-integration of our language and the operating system (Linux in
our case) was also a good learning experience.

\subsection{Jordan}

One of the biggest regrets our group has is not using Java. As someone who 
loves C/C++ and is not a fan of Java, I pushed for this and realize now how 
this was a bad idea. One of the most important parts is the ability to push 
jobs to other machines, but if you have to be able to run code on that 
machine, Java is pretty much necessary if you want to avoid cross-compiling 
for other architectures. In fact, from my 64-bit machine, I cannot even push 
to 32-bit machines with the exact same OS, unless I explicitly tell \verb|g++|
to compile for 32-bit. In addition, we wanted to make lists and maps be able 
to hold objects of any type and many types: this would have been much easier 
in Java, since in C++, we have to cast every object that we return from a 
list. This alone made the code much more complex.

One of the things I had fun with on this project was in developing a role as a 
script guru. The scripts themselves are fairly simple, but some require 
elaborate (read: ugly) hacks. However, making the decision early to delegate 
some of our backend's functions to scripts, as simple as they may be, really 
helped our project. In particular, had we not discovered the expect language, 
which allows you to programmatically respond to outputs of programs, we would 
have been at a complete loss how to manually type the password in when the ssh 
prompts you for a password.

\subsection{Advice to future students}

\begin{itemize}
\item In the initial stages of language design, remember that you have to \emph{implement} whatever you design. Keep the time-frame in mind!
\item Create a testing strategy early on with a good testing framework. write test code in parallel to development.
\item Think carefully about your development environment. Bison and C++ is powerful, and so is ANTLR with Java. Take into account your application-domain and the comfort level of your team with a particular language.
\item Meet at least once a week with your team. This helps avoid late night hackathons and leads to more robust code.
\end{itemize}

\subsection{Suggestions to the instructor}
There were a lot of good things about the course.
The course was comfortably paced with just the right amount of workload. The fact that Bison and other development environments were covered early on was a big help but it would've been nice to learn about testing frameworks early in the course as well. The project was a lot of fun, especially since our project turned out to be quite ambitious and we were determined to pull it through. A guideline regarding the amount of features expected in a language would probably have been helpful especially for teams that may become over-ambitious.

\section*{Appendix}
\addcontentsline{toc}{section}{Appendix}
\appendix
\section{Source code}

%    * Include a listing of the complete source code with identification of who wrote which module of the translator.
\label{sec:code}

\include{code}

\section{Testing code}
\label{sec:test}
\include{test}

\section{Project Log}


\begin{center}
\tablefirsthead{%
  \hline
  Revision & Author & Date \\ \hline}
\tablehead{%
  \hline
  \multicolumn{3}{|p{5in}|}{\small continued from previous page}\\
  \hline
  Revision & Author & Date \\ \hline}
\tabletail{%
  \hline
  \multicolumn{3}{|r|}{\small continued on next page} \\
  \hline}
\tablelasttail{\hline}
\bottomcaption{SVN log for Pigasus.}

\begin{supertabular}{|p{1.7in}|p{1.7in}|p{1.6in}|} \hline

r298 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r297 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r296 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r295 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{My writeup part} \\ \hline \hline 

r294 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{finished unit test for pigasus-test} \\ \hline \hline 

r293 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added tests for cast.cc and minor fixes.} \\ \hline \hline 

r292 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Edited makefile} \\ \hline \hline 

r291 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r290 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added unit test for LoadCSV} \\ \hline \hline 

r289 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Cleaned up directory} \\ \hline \hline 

r288 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed to use the MiniCppUnit} \\ \hline \hline 

r287 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Deleted misc directory. Useless.} \\ \hline \hline 

r286 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r285 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Slight change to ftoc sample} \\ \hline \hline 

r284 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Renamed temp to ftoc} \\ \hline \hline 

r283 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r282 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added gcd sample} \\ \hline \hline 

r281 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{updated gcd.pig} \\ \hline \hline 

r280 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Deleted test video from render sample.} \\ \hline \hline 

r279 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{updated gcd.pig} \\ \hline \hline 

r278 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added gcd.pig} \\ \hline \hline 

r277 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added multiserver tutorial example} \\ \hline \hline 

r276 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added tutorials, minor fixes} \\ \hline \hline 

r275 & J. Rupprecht & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r274 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed wait all and print} \\ \hline \hline 

r273 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed wait all and print} \\ \hline \hline 

r272 & P. Tjimos & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{removed const \&} \\ \hline \hline 

r271 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{moved render.cpp to raytrace.cc, deleted test vid} \\ \hline \hline 

r270 & J. Zhang & Sun, 10 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Minor fix to sample rendering code.} \\ \hline \hline 

r269 & P. Tjimos & Sat, 09 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added function prototypes} \\ \hline \hline 

r268 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r267 & J. Zhang & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added sample program for distributed rendering.} \\ \hline \hline 

r266 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r265 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r264 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added new test for lists} \\ \hline \hline 

r263 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed lists and maps} \\ \hline \hline 

r262 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r261 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r260 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r259 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed list and map addition again} \\ \hline \hline 

r258 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed list and map addition} \\ \hline \hline 

r257 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{footer and grammar and test updated} \\ \hline \hline 

r256 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed footer again} \\ \hline \hline 

r255 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed grammar footer} \\ \hline \hline 

r254 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed grammar footer} \\ \hline \hline 

r253 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r252 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r251 & J. Zhang & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed bug in jobthread that wasn't updating the already\_getting flag} \\ \hline \hline 

r250 & J. Zhang & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added sample files for distcc} \\ \hline \hline 

r249 & J. Rupprecht & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r248 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changed semi-colon with push} \\ \hline \hline 

r247 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{grammar testing and sample files} \\ \hline \hline 

r246 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed list and map bugs} \\ \hline \hline 

r245 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{require wait statements to have ';', added newlines as well} \\ \hline \hline 

r244 & P. Tjimos & Fri, 08 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed missing semi-colon in return} \\ \hline \hline 

r243 & J. Rupprecht & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r242 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added debug info} \\ \hline \hline 

r241 & S. Gururaj & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r240 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed bug in List and added test case. Also fixed sample source for distcc} \\ \hline \hline 

r239 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Removed couts from jobthread, deleted misc-keywords, fixed outputs list in getthread} \\ \hline \hline 

r238 & J. Rupprecht & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r237 & S. Gururaj & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{calling the correct job... not compile always...} \\ \hline \hline 

r236 & J. Rupprecht & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r235 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Edited push.} \\ \hline \hline 

r234 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{include iostream} \\ \hline \hline 

r233 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changed headers for jobs} \\ \hline \hline 

r232 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed runjob and sendthread errors.} \\ \hline \hline 

r231 & S. Gururaj & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Pigmain shouldnt be there where not needed awdfsafdsfsdfdsfsad} \\ \hline \hline 

r230 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed string issues} \\ \hline \hline 

r229 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed buffer} \\ \hline \hline 

r228 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed space in void jobname} \\ \hline \hline 

r227 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{removed const} \\ \hline \hline 

r226 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{removed misc-keywords.h} \\ \hline \hline 

r225 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added misc-keywords.h} \\ \hline \hline 

r224 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added System.h} \\ \hline \hline 

r223 & J. Zhang & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed pigasus sample code} \\ \hline \hline 

r222 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r221 & P. Tjimos & Wed, 06 May 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{cleaned up grammar} \\ \hline \hline 

r220 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed formatstring to accept const list.} \\ \hline \hline 

r219 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r218 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added common.h, fixed typo} \\ \hline \hline 

r217 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changed system to System} \\ \hline \hline 

r216 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed...again} \\ \hline \hline 

r215 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed arg 4 non-null push} \\ \hline \hline 

r214 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed push, wait, etc.} \\ \hline \hline 

r213 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r212 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{made headers look nicer} \\ \hline \hline 

r211 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r210 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{implements the wait keyword} \\ \hline \hline 

r209 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed headers and extern variables} \\ \hline \hline 

r208 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed space} \\ \hline \hline 

r207 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r206 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added distcc.pig} \\ \hline \hline 

r205 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added extra stuff} \\ \hline \hline 

r204 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Removed macro for replacing nulls with empty lists.} \\ \hline \hline 

r203 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r202 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small changes to allow for null, and removed sample PigMain from main.cc.} \\ \hline \hline 

r201 & P. Tjimos & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed nulls} \\ \hline \hline 

r200 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r199 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r198 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Removed grammar files from src top directory.} \\ \hline \hline 

r197 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{moved this to grammar folder} \\ \hline \hline 

r196 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r195 & J. Rupprecht & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r194 & S. Gururaj & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changed list to newlist} \\ \hline \hline 

r193 & J. Zhang & Wed, 29 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Bug introduced! For fixing a bigger bug.} \\ \hline \hline 

r192 & J. Zhang & Tue, 28 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed way inputs is defined in main. This caused a weird problem on my office machine, but not on my vm at home.} \\ \hline \hline 

r191 & J. Zhang & Tue, 28 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added push function, fixed little bugs.} \\ \hline \hline 

r190 & J. Zhang & Tue, 28 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Serializes input now} \\ \hline \hline 

r189 & J. Zhang & Tue, 28 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Implemented copy constructors.} \\ \hline \hline 

r188 & P. Tjimos & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed string and double} \\ \hline \hline 

r187 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r186 & S. Gururaj & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added the main stub} \\ \hline \hline 

r185 & S. Gururaj & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{some file io stuff} \\ \hline \hline 

r184 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{It works (and I'm not taking out debug code...} \\ \hline \hline 

r183 & P. Tjimos & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed return for pigMain} \\ \hline \hline 

r182 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Compiles, bug has some new bugs...} \\ \hline \hline 

r181 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added skeleton for checkdone script and getthread usage in jobthread.} \\ \hline \hline 

r180 & P. Tjimos & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed casting} \\ \hline \hline 

r179 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r178 & S. Gururaj & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{put in the file splitting part} \\ \hline \hline 

r177 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Deleted all references to pollthread} \\ \hline \hline 

r176 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r175 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r174 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r173 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Ooops. Forgot to add pollthread files.} \\ \hline \hline 

r172 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added skeleton for pollthread.} \\ \hline \hline 

r171 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Moved password sending from sendthread to servers} \\ \hline \hline 

r170 & P. Tjimos & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{if else fixed, loops kinda funky} \\ \hline \hline 

r169 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Deleting PostThread} \\ \hline \hline 

r168 & J. Rupprecht & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r167 & J. Zhang & Sun, 26 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed JobThread constructor} \\ \hline \hline 

r166 & J. Zhang & Sat, 25 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Code fixed so that multiple inputs sets can be sent.} \\ \hline \hline 

r165 & J. Zhang & Sat, 25 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Moved debug.h to common.h/.cc. Also some minor changes to debug messages and code style.} \\ \hline \hline 

r164 & J. Zhang & Fri, 24 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Did some cleanup.} \\ \hline \hline 

r163 & J. Zhang & Fri, 24 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{I believe a major flaw has been fixed.} \\ \hline \hline 

r162 & J. Zhang & Thu, 23 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Okay, the last revision included a serious typo.} \\ \hline \hline 

r161 & J. Zhang & Thu, 23 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Okay, the last revision included a serious typo.} \\ \hline \hline 

r160 & J. Zhang & Thu, 23 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Weird test case with ThreadPool} \\ \hline \hline 

r159 & J. Zhang & Thu, 23 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added mutexes around threadpools. Also added type field to threadpools and threads.} \\ \hline \hline 

r158 & J. Rupprecht & Thu, 23 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{compiles with only unused system() return value warnings} \\ \hline \hline 

r157 & P. Tjimos & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{something} \\ \hline \hline 

r156 & J. Rupprecht & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r155 & J. Rupprecht & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r154 & P. Tjimos & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{newest grammar} \\ \hline \hline 

r153 & J. Rupprecht & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r152 & S. Gururaj & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fixed some stuff} \\ \hline \hline 

r151 & J. Zhang & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Implements length and print keywords} \\ \hline \hline 

r150 & J. Zhang & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added CloneValue() function to Pigasus types, and added Casting functions.} \\ \hline \hline 

r149 & J. Zhang & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added new constructors for Map and List} \\ \hline \hline 

r148 & J. Rupprecht & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r147 & P. Tjimos & Wed, 22 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changed lists} \\ \hline \hline 

r146 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Minor comment change. File can be used any way you like.} \\ \hline \hline 

r145 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed pigasus-types to accept consts} \\ \hline \hline 

r144 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Minor stylistic changes.} \\ \hline \hline 

r143 & P. Tjimos & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{fix global\_servers} \\ \hline \hline 

r142 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added formatstring.h} \\ \hline \hline 

r141 & P. Tjimos & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{working distcc grammar (changed last expression on push\_statement to identify and got rid of the semi-colon} \\ \hline \hline 

r140 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Uncleaned format string code.} \\ \hline \hline 

r139 & J. Rupprecht & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r138 & P. Tjimos & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{push implemented...sorta} \\ \hline \hline 

r137 & J. Rupprecht & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r136 & J. Rupprecht & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r135 & J. Rupprecht & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r134 & P. Tjimos & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{changes to push} \\ \hline \hline 

r133 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added file I/O} \\ \hline \hline 

r132 & S. Gururaj & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{list operations supported} \\ \hline \hline 

r131 & J. Zhang & Mon, 20 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Implemented serialization for pigasus types.} \\ \hline \hline 

r130 & J. Rupprecht & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r129 & S. Gururaj & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{2. added the MOD operator (which is the actual remainder operation)} \\ \hline \hline 

r128 & S. Gururaj & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added the MOD operator} \\ \hline \hline 

r127 & S. Gururaj & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r126 & J. Rupprecht & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small type in SendThread} \\ \hline \hline 

r125 & J. Rupprecht & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r124 & J. Zhang & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Minor changes.} \\ \hline \hline 

r123 & J. Rupprecht & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r122 & P. Tjimos & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{grammar has spaces and new lines} \\ \hline \hline 

r121 & J. Rupprecht & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r120 & J. Zhang & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Minor changes to jobthread.*, threadpool.*, added postthread skeleton.} \\ \hline \hline 

r119 & J. Zhang & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Deleting threads.*} \\ \hline \hline 

r118 & J. Zhang & Sun, 19 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Moved ThreadPool out of Threads.h and renamed Threads.h to Thread.h} \\ \hline \hline 

r117 & J. Zhang & Sat, 18 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{minor stylistic changes.} \\ \hline \hline 

r116 & P. Tjimos & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{found couple bugs in grammar, noted them} \\ \hline \hline 

r115 & J. Zhang & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Basic stuff for job threads. Not done.} \\ \hline \hline 

r114 & J. Zhang & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{threads.h will only contain Thread and ThreadPool classes} \\ \hline \hline 

r113 & J. Rupprecht & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r112 & P. Tjimos & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{somewhat working grammar} \\ \hline \hline 

r111 & J. Zhang & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added some comments} \\ \hline \hline 

r110 & J. Zhang & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Implemented ThreadPool} \\ \hline \hline 

r109 & P. Tjimos & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{pigasus-grammar.ypp compiles now} \\ \hline \hline 

r108 & S. Gururaj & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r107 & P. Tjimos & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{declarations.ypp added} \\ \hline \hline 

r106 & P. Tjimos & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{grammar2 added} \\ \hline \hline 

r105 & J. Zhang & Fri, 17 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Basic thread code.} \\ \hline \hline 

r104 & J. Zhang & Mon, 13 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed pigasus-types to accept appends and sets by reference instead of pointers.} \\ \hline \hline 

r103 & P. Tjimos & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{pigasus-grammar .ypp} \\ \hline \hline 

r102 & J. Rupprecht & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{forgot to svn add two files (tests)} \\ \hline \hline 

r101 & J. Rupprecht & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r100 & P. Tjimos & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{update to lex and yacc} \\ \hline \hline 

r99 & P. Tjimos & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{c++ lex scanner and parser} \\ \hline \hline 

r98 & J. Zhang & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added comments to pigasus-types, and added Map's GetKeys()} \\ \hline \hline 

r97 & J. Zhang & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added List concatenation plus test.} \\ \hline \hline 

r96 & J. Zhang & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Forgot to change List.Get to List[] in loadcsv.cc.} \\ \hline \hline 

r95 & J. Zhang & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added [x] access to Lists and Maps. Changed example in loadcsv.cc} \\ \hline \hline 

r94 & J. Zhang & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed LoadCSV to return a List of Maps.} \\ \hline \hline 

r93 & P. Tjimos & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{lex test} \\ \hline \hline 

r92 & S. Gururaj & Sun, 12 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{test suite. good for building from small. this is not the real thing...} \\ \hline \hline 

r91 & J. Zhang & Tue, 07 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added functionality to pigasus-types. Moved tests to separate file.} \\ \hline \hline 

r90 & J. Zhang & Mon, 06 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Made additions to pigasus-types. Added implementations for Map and File.} \\ \hline \hline 

r89 & J. Zhang & Mon, 06 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Rewrote pigasus-types. No longer using derived classes.} \\ \hline \hline 

r88 & J. Zhang & Sun, 05 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed Lists and Maps to contain void*---this allows easy casting.} \\ \hline \hline 

r87 & J. Zhang & Sun, 05 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{LoadCSV is implemented. Does not return List of Maps yet. (Sorry, the other commit were just the test files} \\ \hline \hline 

r86 & J. Zhang & Sun, 05 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{LoadCSV is implemented. Does not return List of Maps yet.} \\ \hline \hline 

r85 & P. Tjimos & Sat, 04 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{updated pigasus.l, test.y} \\ \hline \hline 

r84 & J. Zhang & Sat, 04 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Adds support for Pigasus-specific types.} \\ \hline \hline 

r83 & P. Tjimos & Sat, 04 Apr 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{pigasus.l added} \\ \hline \hline 

r82 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r81 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r80 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{small changes} \\ \hline \hline 

r79 & S. Gururaj & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{small fixes} \\ \hline \hline 

r78 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r77 & S. Gururaj & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added the declarations section for jobs maps files etc} \\ \hline \hline 

r76 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Hacked away 2 bad boxes} \\ \hline \hline 

r75 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added appendix line in lrm} \\ \hline \hline 

r74 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r73 & S. Gururaj & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r72 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added Appendix entry into the TOC} \\ \hline \hline 

r71 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed Grammar to an appendix} \\ \hline \hline 

r70 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r69 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added + unary operator} \\ \hline \hline 

r68 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r67 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{added another tutorial section; cleaned up the LRM} \\ \hline \hline 

r66 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{better code styling; added a tutorial section} \\ \hline \hline 

r65 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Stuff.} \\ \hline \hline 

r64 & J. Zhang & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added intro to tutorial.} \\ \hline \hline 

r63 & P. Tjimos & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{functions} \\ \hline \hline 

r62 & J. Rupprecht & Mon, 30 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{writeup for distcc example} \\ \hline \hline 

r61 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r60 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r59 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{small changes} \\ \hline \hline 

r58 & P. Tjimos & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{more sample code} \\ \hline \hline 

r57 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Completed sections 1 and 2 of the tutorial (initial versions)} \\ \hline \hline 

r56 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added expressions; small fixes.} \\ \hline \hline 

r55 & S. Gururaj & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r54 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Completed first section of tutorial (1a)} \\ \hline \hline 

r53 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added grammar to lrm.tex. Fixed bibliography.} \\ \hline \hline 

r52 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{expand -t2 grammar.txt} \\ \hline \hline 

r51 & S. Gururaj & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r50 & S. Gururaj & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r49 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small changes + bibliography.} \\ \hline \hline 

r48 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Tiny change. Added escaped double quote.} \\ \hline \hline 

r47 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added 'length' keyword.} \\ \hline \hline 

r46 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small change to intro. Changed keyword 'servers' to 'connect'.} \\ \hline \hline 

r45 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added conversion rules between file and string.} \\ \hline \hline 

r44 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Added void to keywords.} \\ \hline \hline 

r43 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed list of keywords.} \\ \hline \hline 

r42 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed the Conversions section.} \\ \hline \hline 

r41 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small changes} \\ \hline \hline 

r40 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small changes} \\ \hline \hline 

r39 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Removed SVN crap.} \\ \hline \hline 

r38 & J. Zhang & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Changed description items to subsections.} \\ \hline \hline 

r37 & J. Rupprecht & Sun, 29 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Small changes; remove .ps and .pdf (unnecessary)} \\ \hline \hline 

r36 & J. Zhang & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Updated intro, new section for types, updated lexical conventions.} \\ \hline \hline 

r35 & J. Rupprecht & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{declarations} \\ \hline \hline 

r34 & J. Rupprecht & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Rough tutorial writeup} \\ \hline \hline 

r33 & S. Gururaj & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{wrote the statements section} \\ \hline \hline 

r32 & J. Rupprecht & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Table of contents} \\ \hline \hline 

r31 & J. Zhang & Sat, 28 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{Fixed comparison operators.} \\ \hline \hline 

r30 & S. Gururaj & Fri, 27 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{updated LRM.} \\ \hline \hline 

r29 & J. Rupprecht & Thu, 26 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r28 & J. Zhang & Sun, 15 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

r27 & J. Zhang & Sat, 14 Mar 2009 \\ \hline 
\multicolumn{3}{|p{5in}|}{} \\ \hline \hline 

\end{supertabular}
\end{center}


\bibliographystyle{abbrv}
\bibliography{final}

\end{document}
